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ABSTRACT 

This  document  specifies  the  Transmission  Control  Protocol  (TCP), 
a  reliable  connection-oriented  transport  protocol  for  use  in 
packet-switched  communication  networks  and  Internetworks.  The 
document  includes  an  overview  with  a  model  of  operation,  a 
description  of  services  offered  to  users,  and  a  description  of 
the  architectural  and  environmental  requirements.  The  protocol 
service  interfaces  and  mechani sulk* are  specified  using  an  extended 
state  machine  model. 
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1 .  OVERVIEW 

This  document  specifies  the  Transmission  Control  Protocol  (TCP),  a  reliable 
connection-oriented  transport  protocol  for  use  in  packet-switched  and  other 
communication  networks  and  interconnected  sets  of  such  networks.  The  document 
is  organized  into  seven  sections  plus  a  bibliography  and  a  glossary  of  terms. 
This,  the  first  section,  establishes  TCP's  role  in  the  evolving  DoD  protocol 
architecture  and  introduces  TCP's  major  services  and  mechanisms.  The  second 
and  third  sections  more  formally  specify  the  services  TCP  offers  to  upper 
layer  protocols  and  the  interface  through  which  those  services  are  accessed. 
Similarly,  the  next  two  sections  specify  the  services  required  of  the  lower 
layer  protocol  and  the  lower  interface.  The  sixth  section  specifies  the 
mechanisms  supporting  the  TCP  services.  The  seventh  section  outlines  the 
functionality  required  of  the  execution  environment  for  successful  TCP  opera¬ 
tion.  The  reader  is  assumed  to  be  familiar  with  the  proposed  DoD  protocol 
architecture  which  defines  a  layered  model  of  network  communications  sys¬ 
tems  [6]  . 

This  document  incorporates  the  organization  and  specification  techniques 
presented  in  the  Protocol  Specification  Gu i de 1 i nes [7] .  One  goal  of  the  guide¬ 
lines  is  to  avoid  assuming  a  particular  system  configuration.  As  a  practical 
matter,  the  distribution  of  protocol  layers  to  specific  hardware  configura¬ 
tions  will  vary.  For  example,  many  computer  systems  are  connected  to  networks 
via  front-end  computers  which  house  TCP  and  lower  layer  protocol  software. 
Although  appearing  to  focus  on  TCP  imp  I ementat ions  which  are  co-resident  with 
the  upper  and  lower  layer  protocols,  this  specification  can  apply  to  any  con¬ 
figuration  given  appropriate  inter-layer  protocols  to  bridge  hardware  boun- 
dar i es . 

TCP  is  desir-’l  to  provide  reliable  communication  between  pairs  of  processes 
in  logically  distinct  hosts  on  networks  and  sets  of  interconnected  networks. 
Thus,  TCP  serves  as  the  basis  for  DoD-wide  i nter-process  communication  in  com¬ 
munication  systems.  TCP  will  operate  successfully  in  an  environment  where  the 
loss,  damage,  duplication,  or  misorder  data,  and  network  congestion  can  occur. 
This  robustness  in  spite  of  unreliable  communications  media  makes  TCP  well 
suited  to  support  military,  governmental,  and  commercial  applications. 

TCP  appears  in  the  DoD  protocol  hierarchy  at  the  transport  layer.  Here,  TCP 
provides  connection-oriented  data  transfer  that  is  reliable,  ordered,  full- 
duplex,  and  flow  controlled.  TCP  is  designed  to  support  a  wide  range  of  upper 
layer  protocols  (ULPs).  The  ULPs  can  channel  continuous  streams  of  data 
through  TCP  for  delivery  to  peer  ULPs.  TCP  breaks  the  streams  into  portions 
which  are  encapsulated  together  with  appropriate  addressing  and  control  infor¬ 
mation  to  form  a  segment--the  unit  of  exchange  Detween  peer  TCPs.  In  turn, 
TCP  passes  segments  to  the  network  layer  for  transmission  through  the  communi¬ 
cation  system  to  the  peer  TCP. 
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+ - +  + - +  + - + 

|Tel net |  j  FTP  |  J  EFTP  |  ... 

+ - +  + - +  + - + 

I  I  I 

+ - +  + - + 

|  TCP  |  |  UDP  | 

+ - +  + - + 


|  INTERNET  PROTOCOL  | 

+ - + 

I 

+ - + 

|  Subnetwork  Protocol  j 

+ - + 

Figure  1.  Example  Host  Protocol  Hierarchy 


The  network  layer  provides  for  data  transfer  between  hosts  attached  to  a  com¬ 
munication  system.  Such  systems  may  range  from  a  single  network  to  intercon¬ 
nected  sets  of  networks  forming  an  internetwork.  The  minimum  required  data 
transfer  service  is  limited;  data  may  be  lost,  duplicated,  misordered,  or  dam¬ 
aged  in  transit.  As  part  the  transfer  service  though,  the  network  layer  must 
provide  global  addressing,  handle  routing,  and  hide  network-specific  charac¬ 
teristics.  As  a  result,  upper  layer  protocols  (including  TCP)  using  the  net¬ 
work  layer  may  operate  above  a  wide  spectrum  of  subnetwork  systems  ranging 
from  hard-wire  connections  to  packet-switched  or  circuit-switched  subnets. 
Additional  services  the  network  layer  may  provide  include  selectable  levels  of 
transmission  quality  such  as  precedence,  reliability,  delay,  and  throughput. 
The  network  layer  also  allows  data  labelling,  needed  in  secure  environments, 
to  associate  security  information  with  data. 

TCP  was  specifically  designed  to  operate  above  the  Internet  Protocol  (IP) 
which  supports  the  interconnection  of  networks[8].  IP's  internet  datagram 
service  provides  the  functionality  described  above.  Originally,  TCP  and  IP 
were  developed  as  a  single  protocol  providing  resource  sharing  across  dif¬ 
ferent  packet  networks[l].  The  need  for  other  transport  protocols  to  use  IP's 
services  led  to  their  specification  as  two  distinct  protocols^,1*]. 

TCP  builds  its  services  on  top  of  the  network  layer's  potentially  unreliable 
ones  with  mechanisms  such  as  error  detection,  positive  acknowledgments, 
sequence  numbers,  and  flow  control.  These  mechanisms  require  certain  address¬ 
ing  and  control  information  to  be  initialized  and  maintained  during  data 
transfer.  This  collection  of  information  is  called  a  TCP  connection.  The 
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following  paragraphs  describe  the  purpose  and  operation  of  the  major  TCP 
mechani sms. 

TCP  uses  a  positive  acknowledgement  with  retransmission  (PAR)  mechanism  to 
recover  from  the  loss  of  a  segment  by  the  lower  layers.  The  strategy  with  PAR 
is  for  a  sending  TCP  to  retransmit  a  segment  at  timed  intervals  until  a  posi¬ 
tive  acknowledgement  is  returned.  The  choice  of  retransmission  interval 
affects  efficiency.  An  interval  that  is  too  long  reduces  data  throughput 
while  one  that  is  too  short  floods  the  transmission  media  with  superfluous 
segments.  A  discussion  of  retransmission  intervals  is  presented  in  [2].  In 
TCP,  the  timeout  is  expected  to  be  dynamically  adjusted  to  approximate  the 
segment  round-trip  time  plus  a  factor  for  internal  processing,  otherwise  per¬ 
formance  degradation  may  occur  [9]. 

TCP  uses  a  simple  checksum  to  detect  segments  damaged  in  transit.  Such  seg¬ 
ments  are  discarded  without  being  acknowledged.  Hence,  damaged  segments  are 
treated  identically  to  lost  segments  and  are  compensated  for  by  the  PAR 
mechanism. 

TCP  assigns  sequence  numbers  to  identify  each  octet  (an  eight  bit  byte)  of  the 
data  stream.  These  enable  3  receiving  TCP  to  detect  duplicate  and  out-of- 
order  segments.  Sequence  numbers  are  also  used  to  extend  the  PAR  mechanism  by 
allowing  a  single  acknowledgment  to  cover  many  segments  worth  of  data.  Thus, 
a  sending  TCP  tan  still  send  new  data  although  previous  data  has  not  been  ack¬ 
nowledged  . 

TCP's  flow  control  mechanism  enables  a  receiving  TCP  to  govern  the  amount  of 
data  dispatched  by  a  sending  TCP.  The  mechanism  is  based  on  a  "window"  which 
defines  a  contiguous  interval  of  acceptable  sequence  numbered  data.  As  data 
is  accepted,  TCP  slides  the  window  upward  in  the  sequence  number  space.  This 
window  is  carried  in  every  segment  enabling  peer  TCPs  to  maintain  up-to-date 
window  information. 

TCP  employs  a  multiplexing  mechanism  to  allow  multiple  ULPs  within  a  single 
host  and  multiple  proccesses  in  a  UIP  to  use  TCP  simultaneously.  This  mechan¬ 
ism  associates  identifiers,  called  ports,  to  ULP's  processes  accessing  TCP 
services.  A  ULP  connection  is  uniquely  identified  with  a  socket,  the  concate¬ 
nation  of  a  port  and  an  internet  address.  Each  connection,  is  uniquely  named 
with  a  socket  pair.  This  naming  scheme  allows  a  single  ULP  to  support  connec¬ 
tions  to  multiple  remote  ULPs.  ULPs  which  provide  popular  resources  are 
assigned  permanent  sockets,  called  well-known  sockets.  Some  well-known  sock¬ 
ets  currently  used  in  DoD  networks  are  published  in  in  [5] . 

When  two  ULPs  wish  to  to  communicate,  they  instruct  their  TCP’s  to  initialize 
and  synchronize  the  mechanism  information  on  each  to  open  the  connection. 
However,  the  potentially  unreliable  network  layer  can  complicate  the  process 
of  synchronization.  Delayed  or  duplicate  segments  from  previous  connection 
attempts  might  be  mistaken  for  new  ones.  A  handshake  procedure  with  clock 
based  sequence  numbers  is  used  in  connection  opening  to  reduce  the  possibility 
of  such  false  connections.  In  the  simplest  handshake,  the  TCP  pair  synchron¬ 
izes  sequence  numbers  by  exchanging  three  segments,  thus  the  name  three-way 
handshake.  The  scenario  following  the  overview  depicts  this  exchange.  The 
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procedure  will  be  discussed  more  fully  in  the  mechanism  descriptions.  Section 
6.1.  A  comprehensive  study  of  connection  establishment  and  related  connection 
management  issues  can  be  found  in  [10], 


A  UIP  can  open  a  connection  in  one  of  two  modes,  passive  or  active.  With  a 
passive  open  a  ULP  instructs  its  TCP  to  be  "receptive"  to  connections  with 
other  ULPs.  With  an  active  open  a  ULP  instructs  its  TCP  to  actively  initiate 
a  three-way  handshake  to  connect  to  another  ULP.  Usually,  an  active  open  is 
targeted  to  a  passive  open.  This  active/passive  model  supports  server- 
oriented  applications  where  a  permanent  resource,  such  as  a  data-base  manage¬ 
ment  process,  can  always  be  accessed  by  remote  users.  However,  the  three-way 
handshake  also  coordinates  two  simultaneous  active  opens  to  open  a  connection. 


Over  an  open  connection,  the  ULP-pair  can  exchange  a  continuous  stream  of  data 
in  both  directions.  Normally,  TCP  transparently  groups  the  data  into  TCP  seg¬ 
ments  for  transmission  at  its  own  convenience.  However,  a  ULP  can  exercise  a 
"push"  service  to  force  TCP  to  package  and  send  data  passed  up  to  that  point 
without  waiting  for  additional  data.  This  mechanism  is  intended  to  prevent 
possible  deadlock  situations  where  a  ULP  waits  for  data  internally  buffered  by 
TCP.  For  example,  an  interactive  editor  might  wait  forever  for  a  single  input 
line  from  a  terminal.  A  push  will  force  data  through  the  TCPs  to  the  awaiting 
process.  TCP  also  provides  a  means  for  a  sending  ULP  to  indicate  to  a  receiv¬ 
ing  ULP  that  "urgent"  data  appears  in  the  upcoming  data  stream.  This  urgent 
mechanism  can  support,  for  example,  interrupts  or  breaks. 


When  data 
free  TCP 
two  ways, 
handshake 
the  TCPs. 
result  in 


exchange  is  complete  the  connection  can  be  closed  by  either  ULP  to 
resources  for  other  connections.  Connection  closing  can  happen  in 
The  first,  called  a  graceful  close,  is  based  on  the  three-way 
procedure  to  complete  data  exchange  and  coordinate  closure  between 
The  second,  called  an  abort,  does  not  allow  coordination  and  may 
loss  of  unacknowledged  data. 
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1 . 1  SCENARIO 


The  following  scenario  provides  a  walk-through  of  a  connection  opening,  data 
exchange,  and  a  connection  closing  as  might  occur  between  the  data  base 
management  process  and  user  mentioned  above.  The  scenario  glosses  over  many 
details  to  focus  on  the  three-way  handshake  mechanism  in  connection  opening 
and  closing,  and  the  positive  acknowledgement  with  retransmission  mechanism 
supporting  reliable  data  transfer.  Although  not  pictured,  the  network  layer 
transfers  the  information  between  the  TCPs.  For  the  purposes  of  this  scenario, 
the  network  layer  is  assumed  not  to  damage,  lose,  duplicate,  or  change  the 
order  of  data  unless  explicitly  noted. 

The  scenario  is  organized  into  three  parts: 

a.  A  simple  connection  opening  in  steps  1-7- 

b.  Two-way  data  transfer  in  steps  8-17- 

c.  A  graceful  connection  close  in  steps  1 8—25 - 


used  in  the  diagrams: 


The  following  notation  is 

<—  SEQ#  200  <— 

— >  ACK#  201  — > 

:  t 

SEND  DATA  : 

:  DELIVER  DATA 

v  : 


depicts  information  exchange 
between  peer  TCPs 

depicts  information  passing 
across  the  interface  between 
a  ULP  and  i ts  TCP 


)  ULP  A  |  |  ULP  B  | 


2. ACTIVE  OPEN  1. PASSIVE  OPEN 

TO  B  : 


v -  - v 


— >  3- SYN  SEQ#200  — > 

TCP  A 

TCP  B 

1.  ULP  B  (the  DB  manager)  issues  a  PASSIVE  OPEN  to  TCP  B  to  prepare  for  con¬ 
nection  attempts  from  other  ULPs  in  the  system. 

2.  ULP  A  (the  user)  issues  an  ACTIVE  OPEN  to  open  a  connection  to  ULP  B. 

3.  TCP  A  sends  a  segment  to  TCP  B  with  an  OPEN  control  flag,  called  a  SYN, 
carrying  the  first  sequence  number  (shown  as  SEQ#200)  it  will  use  for 
data  sent  to  6. 
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|  ULP  A 


|  ULP  B 
- 1— - 


6. CONNECTION  OPEN 
TO  B 


7. CONNECTION  OPEN 
TO  A 


<--  k.ACK#201  ;SYN  SEQ#550  <— 

TCP  A 

TCP  B 

->  5-ACK#551 


k.  TCP  B  responds  to  the  SYN  by  sending  a  positive  acknowledgement  ACK, 

marked  with  next  sequence  number  expected  from  TCP  A.  In  the  ~>e  seg¬ 

ment,  TCP  B  sends  its  own  SYN  with  the  first  sequence  number  r  its 
data  (SEQ#550) . 

5.  TCP  A  responds  to  TCP  B's  SYN  with  an  ACK  showing  the  next  sequence 
number  expected  from  B. 

6.  TCP  A  now  informs  ULP  A  that  a  connection  is  open  to  ULP  B. 

7.  Upon  receiving  the  ACK,  TCP  B  informs  ULP  B  that  a  connection  has  been 
opened  to  ULP  A. 


|  ULP  A  | 
«  _  _  • 

8. SEND  DATA 


|  ULP  B  | 
- 1 - 


10. DELIVER  DATA 


- > 

9. DATA  SEQ#20 1 

--> 

TCP  A 

TCP  B 

< — 


8.  ULP  A  passes  20  octets  of  data  to  TCP  A  for  transfer  across  the  open  con¬ 
nection  to  ULP  B. 


9.  TCP  A  packages  the  data  in  a  segment  marked  with  current  "A"  sequence 
number . 


10.  After  validating  the  sequence  number,  TCP  B  accepts  the  data  and  delivers 
i  t  to  ULP  B . 

11.  TCP  B  acknowledges  all  20  octets  of  data  with  the  ACK  set  to  the  sequence 
number  of  the  next  data  octet  expected. 


r 
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|  ULP  A  |  |  ULP  B  | 

- f -  - . - 

1A. DELIVER  DATA  12. SEND  DATA 


v 


<--  13. DATA  S E Q#55 1 

<-- 

-->  15.  ACK  #676  XXXXXXXXXXXX 

TCP  A 

<—  16. DATA  SEQ#551 

-->  17. ACK  #67 8 

<-- 

--> 

TCP  B 

12.  ULP  B  passes  125  bytes  of  data  to  TCP  B  for  transfer  to  ULP  A. 

13-  TCP  B  packages  the  data  in  a  segment  marked  with  the  "B"  sequence  number. 

1A.  TCP  A  accepts  the  segment  and  delivers  the  data  to  ULP  A. 

15-  TCP  A  returns  an  ACK  of  the  received  data  marked  with  the  sequence  number 

of  the  next  expected  data  octet.  However,  the  segment  is  lost  by  the 

network  and  never  arrives  at  TCP  B. 

16.  TCP  B  times  out  waiting  for  the  lost  ACK  and  retransmits  the  segment. 
TCP  A  receives  the  retransmi tted  segment,  but  oiscards  i  because  the 
data  from  the  original  segment  has  already  been  accepted.  However,  TCP  A 
re-sends  the  ACK. 

17.  TCP  B  gets  the  second  ACK. 


|  ULP  A  j  |  ULP  B  | 

—  - -  - 1 - 

18. CLOSE  TO  B  20. ULP  A  CLOSING 


v 


19.  FIN  SEQ#22 1 

--> 

TCP  A 

TCP  B 

18.  ULP  A  closes  its  half  of  the  connection  by  issuing  a  CLOSE  to  TCP  A. 

19.  TCP  A  sends  a  segment  marked  with  a  CLOSE  control  flag,  called  a  FIN,  to 
inform  TCP  B  that  ULP  A  wi I  1  send  no  more  data. 


20.  TCP  B  gets  the  FIN  and  informs  ULP  B  that  ULP  A  is  closing. 


I 
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|  ULP  A  |  |  ULP  B  | 

—  t .  . : - 

24. CONNECTION  CLOSED  21. CLOSE  TO  A 


v 


<—  22.  FIN  SEQ#67&,ACK#222  <” 

TCP  A 

TCP  B 

- . >  23.  ACK#677  — > 


21.  ULP  B  completes  its  data  transfer  and  closes  its  half  of  the  connection. 

22.  TCP  B  sends  an  ACK  of  the  first  FIN  and  its  own  FIN  to  TCP  A  to  show  ULP 
B 1 s  closing. 

23.  TCP  A  gets  the  FIN  and  the  ACK,  then  responds  with  an  ACK  to  TCP  B. 

24.  TCP  A  informs  ULP  A  that  the  connection  is  closed. 

25.  (Not  pictured)  TCP  B  receives  the  ACK  from  TCP  A  and  informs  ULP  B  that 
the  connection  is  closed. 
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2.  SERVICES  PROVIDED  TO  UPPER  LAYER 

This  section  describes  the  services  offered  by  the  Transmission  Control  Proto¬ 
col  to  upper  layer  protocols  (ULPs).  The  goals  of  this  section  are  to  provide 
the  motivation  for  protocol  mechanisms  and  to  provide  ULPs  with  a  definition 
of  the  functions  provided  by  this  protocol. 

The  services  provided  by  TCP  can  be  organized  as  follows: 

o  multiplexing  service 

o  connection  management  services 

o  data  transport  service 

o  error  reporting  service 

A  description  of  each  service  follows. 

2.1  MULTIPLEXING  SERVICE 

TCP  shall  provide  services  to  multiple  pairs  of  processes  within  upper  layer 
protocols.  A  process  within  a  ULP  using  TCP  services  shall  be  identified  with 
a  "port".  A  port,  when  concatenated  with  an  internet  address,  forms  a  socket 
which  uniquely  names  a  ULP  throughout  the  internet.  TCP  shall  use  the  pair  of 
sockets  corresponding  to  a  connection  to  differentiate  between  multiple  users. 

2.2  CONNECTION  MANAGEMENT  SERVICE 

TCP  shall  provide  data  transfer  capabilities,  called  connections,  between 
pairs  of  upper  layer  protocols.  A  connection  provides  a  communication  channel 
between  two  ULPs.  Characteristics  of  data  transfer  are  specified  in  the  data 
transfer  service  description.  Connection  management  can  be  broken  into  three 
phases:  connection  establishment,  connection  maintenance,  and  connection  ter¬ 
mination. 

2.2.1  Connection  Establishment 

TCP  shall  provide  a  means  to  open  connections  between  ULP-pairs.  Connections 
are  endowed  with  certain  properties  that  apply  for  the  !ifetime  of  the  connec¬ 
tion.  These  properties,  including  security  and  precedence  levels,  are  speci¬ 
fied  by  the  ULPs  at  connection  opening.  Connections  can  be  opened  in  one  of 
two  modes:  active  or  passive. 

TCP  shall  provide  a  means  for  a  ULP  to  actively  initiate  a  connection  to 
another  ULP  uniquely  named  with  a  socket.  TCP  shall  establish  a  connection  to 
the  named  ULP  if: 

1.  no  connection  between  the  two  named  sockets  already  exists, 

2.  internal  TCP  resources  are  sufficient. 
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3.  the  other  ULP  exists,  and  has 

a.  simultaneously  executed  a  matching  active  open  to  this  ULP, 

b.  cr,  previously  executed  a  matching  passive  open, 

c.  or,  previously  executed  a  "global11  matching  passive  open 

TCP  shall  provide  a  means  for  a  ULP  to  listen  for  and  respond  to  active  opens 
from  correspondent  ULPs.  Correspondent  ULPs  are  named  in  one  of  two  ways: 

1.  fully  specified  :  A  ULP  is  uniquely  named  by  a  socket.  A  connection  is 
established  when  a  matching  active  open  is  executed  (as  described  above) 
by  the  named  ULP. 

2.  unspecified  :  No  socket  is  provided.  A  connection  is  established  with 
any  ULP  executing  an  matching  active  open  naming  this  ULP. 

2.2.2  Connection  Maintenance 

TCP  shall  maintain  established  connections  supporting  the  data  transfer  ser¬ 
vice  described  in  Section  2.3*  And,  TCP  shall  provide  a  means  for  a  ULP  to 
acquire  current  connection  status  with  regard  to  connection  name,  data 
transfer  progress,  and  connection  qualities. 

• 

2.2.3  Connection  Termination 

TCP  shall  provide  a  means  to  terminate  established  connections  and  nullify 
connection  attempts.  Established  connections  can  be  terminated  in  two  ways: 

1.  Graceful  Close  :  Both  ULPs  close  their  side  of  the  duplex  connection, 
either  simultaneously  or  sequentially,  when  data  transfer  is  complete. 
TCP  shall  coordinate  connection  termination  and  prevent  loss  of  data  in 
transit  as  promised  by  the  data  transfer  service. 

2.  Abort  :  One  ULP  independently  forces  closure  of  the  connection.  TCP 

shall  not  coordinate  connection  termination.  Any  data  in  transit  may  be 

lost . 

2.3  DATA  TRANSPORT  SERVICE 

TCP  shall  provide  data  transport  over  established  connections  between  ULP- 

pairs.  The  data  transport  is  full-duplex,  timely,  ordered,  labelled  with 
security  and  precedence  levels,  flow  controlled,  and  error-checked.  A  more 
detailed  description  of  each  of  the  data  transport  characteristics  follows. 

-  full-duplex  :  TCP  shall  support  simultaneous  bi-directional  data  flow 

between  the  correspondent  ULPs. 

-  timely:  When  system  conditions  prevent  timely  delivery,  as  specified  by 
the  user  timeout,  TCP  shall  notify  the  local  ULP  of  service  failure  and 
subsequently  terminate  the  connection. 
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-  ordered  :  TCP  shall  deliver  data  to  a  destination  ULP  in  the  same 
sequence  as  it  was  provided  by  the  source  ULP. 

-  labelled  :  TCP  shall  associate  with  each  connection  with  the  security  and 
precedence  levels  supplied  by  the  ULPs  during  connection  establishment. 
When  this  information  is  not  provided  by  the  ULP-pair,  TCP  shall  assume 
default  levels.  TCP  shall  establish  a  connection  between  a  ULP-pair  only 
if  the  security/compartment  information  exactly  matches.  If  the  pre¬ 
cedence  levels  do  not  match  during  connection,  the  higher  precedence 
level  is  associated  with  the  connection. 

-  flow  controlled  :  TCP  shall  regulate  the  flow  of  data  across  the  connec¬ 
tion  to  prevent,  among  other  things,  internal  TCP  congestion  leading  to 
service  degradation  and  failure. 

-  error  checked  :  TCP  shall  deliver  data  that  is  free  of  errors  within  the 
probabilities  supported  by  a  simple  checksum. 

TCP  shall  provide  two  capabilities  to  ULPs  concerning  data  transfer  over  an 
established  connection:  data  stream  push  and  urgent  data  signalling. 

-  data  stream  push  :  TCP  shall  transmit  any  waiting  data  up  to  and  includ¬ 
ing  the  indicated  data  portions  to  the  receiving  TCP  without  waiting  for 
additional  data.  The  receiving  TCP  shall  deliver  the  data  to  the  receiv¬ 
ing  ULP  in  the  same  manner. 

-  urgent  data  signalling  :  TCP  shall  provide  a  means  for  a  sending  ULP  to 
inform  a  receiving  ULP  of  the  presence  of  significant,  or  "urgent,"  data 
in  the  upcoming  data  stream. 

2.k  ERROR  REPORTING  SERVICE 

TCP  shall  report  service  failure  stemming  from  catastrophic  conditions  in  the 
internetwork  environment  for  which  TCP  cannot  compensate. 
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3.  UPPER  LAYER  SERV I C£/ I NTERf ACE  SPECIFICATIONS 

This  section  specifies  the  TCP  services  provided  to  upper  layer  protocols  and 
the  interface  through  which  these  services  are  accessed.  The  first  part 
defines  the  interaction  primitives  and  interface  parameters  for  the  upper 
interface.  The  second  part  contains  the  extended  state  machine  specification 
of  the  upper  layer  services  and  interaction  discipline. 


3.1  INTERACTION  PRIMITIVES 

An  interaction  primitive  defines  the  information  exchanged  between  two  adja¬ 
cent  protocol  layers.  Primitives  are  grouped  into  two  classes  based  on  the 
direction  of  information  flow.  Information  passed  downward,  in  this  case  from 
a  ULP  to  TCP,  is  called  a  service  request  primitive.  Information  passed 
upward,  from  TCP  to  the  ULP,  is  called  a  service  response  primitive.  Interac¬ 
tion  primitives  need  not  occur  in  pairs.  That  is,  a  service  request  does  not 
necessarily  elicit  a  service  "response";  a  se. vice  "response"  may  occur 
independently  of  a  service  request. 

The  information  associated  with  an  interaction  primitive  falls  into  two 
categories:  parameters  and  data.  Parameters  describe  the  data  and  indicate 
how  it  is  to  be  treated.  The  data  itself  is  neither  examined  nor  modified. 
The  format  of  the  parameters  and  data  is  implementation  dependent  and  there¬ 
fore  not  spec i f i ed . 

TCP  implementations  may  have  different  interaction  primitives  imposed  by  the 
execution  environment  or  system  design  factors.  In  those  cases,  the  primi¬ 
tives  can  be  modified  to  include  more  information  or  additional  primitives  can 
be  defined  to  satisfy  system  requirements.  However,  all  TCPs  must  provide  at 
least  the  information  found  in  the  interaction  primitives  specified  below  to 
guarantee  that  all  TCP  implementations  can  support  the  same  protocol  hierar¬ 
chy.  Additional  primitives  that  affect  the  protocol  mechanisms  may  not  be 
used . 


3.1.1  Service  Request  Primitives 

The  TCP  service  request  primitives  enable  connection  establishment,  data 
transfer,  and  connection  termination.  The  request  primitives  are: 

1.  Unspecified  Passive  Open, 

2.  Fully  Specified  Passive  Open, 

3.  Active  Open, 

U.  Active  Open  With  Data, 

5*  Send, 

6.  Al locate. 
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7.  Close, 

8.  Abort,  and 
9*  Status. 

A  description  and  list  of  parameters  for  each  service  request  follows. 
Optional  service  request  parameters  are  followed  by  "[optional]." 

3. 1.1.1  Unspec i f i ed  Pass i ve  Open  This  service  request  primitive  allows  a  ULP 
to  listen  for  and  respond  to  connection  attempts  from  an  un-named  ULP  at  a 
specified  security  and  precedence  level.  TCP  accepts  in  an  Unspecified  Pas¬ 
sive  Open  at  least  the  following  information: 

-  source  port 

-  ULP  timeout  [optional] 

-  precedence  [optional] 

-  security  [optional] 

3. 1.1. 2  Fully  Spec i f i ed  Passive  Open  This  service  request  primitive  allows  a 
ULP  to  listen  for  and  respond  to  connection  attempts  from  a  fully  named  ULP  at 
a  particular  security  and  precedence  level.  TCP  accepts  in  an  Fully  Specified 
Passive  Open  at  least  the  following  information: 

-  source  port 

-  destination  port 

-  destination  address 

-  ULP  timeout  [optional] 

-  precedence  [optional] 

-  security  [optional] 

3-1. 1*3  Active  Open  This  service  request  primitive  allows  a  ULP  to  initiate 
a  connection  attempt  to  a  named  ULP  at  a  particular  security  and  precedence 
level.  TCP  accepts  in  an  Active  Open  at  least  the  following  information: 

-  source  port 

-  destination  port 

-  destination  address 

-  ULP  timeout  [optional] 
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-  precedence  [optional] 

-  security  [optional] 

3. 1.1.4  Active  Open  Wi  th  Data  This  service  request  primitive  allows  a  ULP  to 
initiate  a  connection  attempt  to  a  named  ULP  at  a  particular  security  and  pre¬ 
cedence  level  accompanied  by  the  specified  data.  TCP  accepts  in  an  Active 
Open  With  Data  at  least  the  following  information: 

-  source  port 

-  destination  port 

-  destination  address 

-  ULP  timeout  [optional] 

-  precedence  [optional] 

-  security  [optional] 

-  data 

-  data  length 

> 

-  PUSH  flag 

-  URGENT  flag 

3. 1.1. 5  Send  This  service  request  primitive  causes  data  to  be  transferred 
across  the  named  connection.  TCP  accepts  in  a  Send  at  least  the  following 
i nf ormat i on: 

-  local  connection  name 

-  data 

-  data  length 

-  PUSH  flag 

-  URGENT  flag 

-  ULP  timeout  [optional] 

3. 1.1. 6  A1 locate  This  service  request  primitive  allows  a  ULP  to  issue  TCP  an 
incremental  allocation  for  receive  data.  The  parameter,  data  length,  is 
defined  in  single  octet  units.  This  quantity  is  the  additional  number  of 
octets  which  the  receiving  ULP  is  willing  to  accept.  TCP  accepts  in  a  Allo¬ 
cate  at  least  the  following  information: 
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-  local  connection  name 

-  data  length 

3. 1.1. 7  C 1 ose  This  service  request  primitive  allows  a  ULP  to  indicate  that 
it  has  completed  data  transfer  across  the  named  connection.  TCP  accepts  in  a 
Close  at  least  the  following  information: 

-  local  connection  name 

3. 1.1. 8  Abort  This  service  request  primitive  allows  a  ULP  to  indicate  that 
the  named  connection  is  to  be  immediately  terminated.  TCP  accepts  in  an  Abort 
at  least  the  following  information: 

-  local  connection  name 

3. 1.1.9  Status  This  service  request  primitive  allows  a  ULP  to  query  for  the 
current  status  of  the  named  connection.  TCP  accepts  in  an  Status  at  least  the 
following  information: 

-  local  connection  name 

TCP  returns  the  requested  status  information  in  a  Status  Response,  defined  in 
Section  3. 1.2. 7  below. 


3.1.2  Service  Response  Primitives 

Several  service  response  primitives  are  provided  to  enable  TCP  to  inform  the 
user  of  connection  status,  data  delivery,  connection  termination,  and  error 
conditions.  The  response  primitives  are  Open  Id,  Open  Failure,  Open  Success, 
Deliver,  Closing,  Terminate,  Status  Response,  and  Error.  Each  is  fully 
defined  in  the  following  paragraphs. 

3. 1.2.1  Open  I d  This  service  response  primitive  informs  a  ULP  of  the  local 
connection  name  assigned  by  TCP  to  the  connection  requested  in  one  of  the  pre¬ 
vious  service  requests.  Unspecified  Open,  Fully  Specified  Open,  or  an  Active 
Open.  TCP  provides  in  an  Open  Id  at  least  the  following  information: 

-  local  connection  name 

-  source  port 

-  destination  port  [if  known] 

-  destination  address  [if  known] 

3. 1.2. 2  Open  Fai lure  This  service  response  primitive  informs  a  ULP  of  the 
failure  of  an  Active  Open  service  request.  TCP  provides  in  an  Open  Failure  at 
least  the  following  information: 


local  connection  name 
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3- 1.2. 3  Open  Success  This  service  response  primitive  informs  a  ULP  of  the 
completion  of  one  of  the  Open  service  requests.  TCP  provides  in  an  Open  Suc¬ 
cess  at  least  the  following  information: 

-  local  connection  name 

3. 1.2. I*  De 1 i ver  This  service  response  primitive  informs  a  ULP  of  the  arrival 

of  data  across  the  named  connection.  TCP  provides  in  a  Deliver  at  least  the 

following  information: 

-  local  connection  name 

-  data 

-  data  length 

-  URGENT  flag 

3. 1.2. 5  Closing  This  service  response  primitive  informs  a  ULP  that  the  peer 

ULP  has  issued  a  CLOSE  service  request.  Also,  TCP  has  delivered  all  data  sent 

by  the  remote  ULP.  TCP  provides  in  a  Closing  at  least  the  following  informa¬ 
tion: 

-  local  connection  name 


3. 1.2. 6  Term! nate  This  service  response  primitive  informs  a  ULP  that  the 
named  connection  has  been  terminated  and  no  longer  exists.  TCP  generates  this 
response  as  a  result  of  a  remote  connection  reset,  service  failure,  and  con¬ 
nection  closing  by  the  local  ULP.  TCP  provides  in  a  Terminate  at  least  the 
following  information: 

-  local  connection  name 

-  description 


3-1. 2. 7  Status  Response  This  service  response  primitive  returns  to  a  ULP  the 
current  status  information  associated  with  a  connection  named  in  a  previous 
Status  service  request.  TCP  provides  in  a  Status  Response  at  least  the  fol¬ 
lowing  information: 

-  local  connection  name 

-  source  port 

-  source  address 

-  destination  port 


-  destination  address 
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-  connection  state 


-  amount 

of 

data 

i  n 

octets 

willing 

to  be  accepted 

by  the 

local  TCP 

-  amount 

of 

data 

i  n 

octets 

al lowed 

to  send  to  the 

remote 

TCP 

-  amount 

of 

data 

i  n 

octets 

awa i t ing 

acknowledgement 

-  amount 

of 

data 

i  n 

octets 

pend i ng 

receipt  by  the 

local 

ULP 

-  urgent  state 

-  precedence 

-  secur i ty 

-  ULP  timeout 

3. 1.2. 8  Error  This  service  response  primitive  informs  a  ULP  of  illegal  ser¬ 
vice  requests  relating  to  the  named  connection  or  of  errors  relating  to  the 
environment.  TCP  provides  in  an  Error  response  at  least  the  following  infor¬ 
mat  i  on: 

-  local  connection  name 


error  description 


6  July  1982 


-18- 


System  Development  Corporation 
TM-7172A82/00 


3.2  EXTENDED  STATE  MACHINE  SPECIFICATION  SERVICES  PROVIDED  TO  UPPER  LAYER 

TCP  performs  in  a  distributed  environment.  Hence,  an  effective  model  of  TCP 
services  can  be  constructed  through  the  composition  of  two  extended  state 
machines,  called  local  service  machines.  The  following  diagram  shows  a  sum¬ 
mary  of  this  "split-state"  model. 


|  ULP  A 


|  ULP  B 


requests 


responses 


requests  | 

]  responses 


. v - I - 

Local  Service 
Mach i ne  A 


state_vector__A 

<savai 


— -v - | - 

Local  Service 
Machine  B 

state_vector_B 

**> 


|  EXCHANGE 


TCP  COMPOSITE  SERVICE  MACHINE 


Split  State  Model  of  TCP  Services 


Each  local  machine  is  coupled  with  one  ULP  of 
stimuli  to  its  local  service  machine,  in 
receives  the  resulting  reactions,  as  service 
maintains  a  complete  state  record,  called  a 
perspective  of  the  state  of  the  connection, 
local  machines  exchange  information  (denoted 
t ion  delay. 


the  ULP-pair.  Each  ULP  provides 
the  form  of  service  requests,  and 
responses.  Each  local  machine 
state  vector,  maintaining  a  local 
At  undetermined  intervals,  the 
by  EXCHANGE)  modelling  communica- 


An  extended  state  machine  definition  is  composed  of  a  machine  identifier,  a 
state  diagram,  a  state  vector,  a  set  of  data  structures,  an  event  list,  and  an 
events  and  actions  correspondence. 

3.2.1  Machine  Instantiation  Identifier 

Each  local  service  machine  is  uniquely  identified  by  the  values: 
o  port  of  ULP  A 
o  address  of  ULP  A 


o  port  of  ULP  B 
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o  address  of  ULP  B 

After  the  first  open  service  request,  a  TCP  uses  a  shorter  name,  called  a 
local  connection  name,  to  identify  a  connection  in  the  interactions  with  its 
co-resident  ULP. 

The  Unspecified  Passive  Open  service  request  does  not  designate  the  port  and 
address  of  the  remote  ULP  and  such  "half-named"  service  machines  are  dis¬ 
tinguished  by  local  connection  name.  A  fully-named  service  machine  (if  it 
exists)  will  be  connected  to  a  remote  open  request  rather  than  a  half-named 
service  machine  with  the  same  source  port  and  source  address.  Then,  if  more 
than  one  half-named  service  machine  exists,  they  are  connected  to  matching 
fully-named  remote  open  requests  at  random. 

3.2.2  State  Diagrams 

Because  of  the  split-state  model  presented,  both  the  local  service  machine 
state  diagram  and  the  composite  service  machine  state  diagram  are  presented. 

The  following  diagram  summarizes  the  service  provided  by  the  composite  TCP 
service  machine  as  derived  from  the  composition  of  two  local  service  machines. 
The  boxes  represent  the  state  of  the  composite  service  machine;  the  arrows 
represent  state  transitions  resulting  from  the  service  requests  and  service 
responses  shown.  The  "EX"  labels  represent  state  changes  resulting  from  the 
periodic  exchanges  between  local  service  machines.  This  diagram  serves  only 
as  a  guide  and  does  not  supersede  the  full  definition  of  the  composite  service 
machine  in  Section  3-2.  Abnormal  connection  termination  states  are  enclosed 
in  the  dotted  box.  These  states  result  from  an  Abort  service  request  or  from 
TCP  service  failure. 
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COMPOSITE  TCP  SERVICE  STATE  MACHINE  DIAGRAM 
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ULP  Service  Requests 


TCP  Internal  Events 


PO 

-  passive  open, 

EX 

-  exchange  of  state 

either  unspecified 

information  between  local 

or  fully  spec i f i ed 

servi ce  enti ti es 

AO 

-  active  open 

T 

-  termination  of  service 

S 

-  send 

due  to  service  failure 

C 

-  close 

OF 

-  open  fail,  active  open 

Ab 

-  abort  (forces  to  CLOSED) 

request  failed 

Note:  The  first  "actor"  of  the  ULP-pair  is  defined  to  be 
ULP  A,  as  shown  by  the  notation  PO/A,  or  AO/A. 
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The  preceding  diagram  summarizes  the  definition  of  the  service  state  machine 
for  the  local  service  machine  appearing  in  Section  3.2.  This  diagram  presents 
the  sequence  of  state  changes  from  the  point  of  view  of  a  single  ULP  accessing 
TCP's  services.  The  boxes  represent  the  states  of  the  state  machine;  the 
arrows  represent  state  transitions  resulting  from  the  service  requests  and 
service  responses  shown.  Please  note  that  the  diagram  is  intended  only  as  a 
summary  and  does  not  supersede  the  formal  definition  of  Section  3*2. 


3.2.3  State  Vector 

The  service  machine  vector  of  a  local  service  machine  consists  of  the  follow¬ 
ing  elements: 

1.  state  =  (CLOSED.  ACTIVE  OPEN,  PASSIVE  OPEN, 

ESTABLISHED,  CLOSING); 

2.  source  port  -  identifier  of  the  local  ULP. 

3.  source  address  -  internet  address  identifying  the  location  of  the  local 
ULP. 

1*.  destination  port  -  identifier  of  the  remote  ULP. 

5.  destination  address  -  internet  address  identifying  the  location  of  the 
remote  ULP. 

6.  local  connection  name  -  the  shorthand  identifier  used  in  all  service 
responses  and  service  requests  except  for  open  requests. 

7.  original  precedence  -  precedence  level  specified  by  the  local  ULP  in  the 
open  request. 

8.  actual  precedence  -  precedence  level  negotiated  at  connection  opening  and 
used  during  connection  lifetime. 

9-  security  -  security  information  (including  security  level,  compartment, 
handling  restrictions,  and  transmission  control  code)  defined  by  the 
local  ULP. 

10.  ULP  timeout  -  the  longest  delay  allowed  for  data  delivery  before 
automatic  connection  termination. 

11.  open  mode  -  the  type  of  open  request  issued  by  the  local  ULP  including 
UNPASSIVE,  FULLPASS I VE ,  and  ACTIVE. 

12.  send  queue  -  storage  location  of  data  sent  by  the  local  ULP  before 
transmission  to  the  remote  TCP.  Each  data  octet  is  stored  with  a  times¬ 
tamp  indicating  its  time  of  entry. 


13*  send  queue  length  -  number  of  entries  in  the  reev  queue  made  up  of  data 
and  timestamp  information. 
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14.  send  push  -  an  offset  from  the  front  of  the  send  queue  indicating  the  end 
of  push  data. 

15-  send  urgent  -  an  offset  from  the  front  of  the  end  queue  indicating  the 
end  of  urgent  data. 

16.  receive  queue  -  storage  location  of  data  received  from  the  remote  TCP 
before  delivery  to  the  local  ULP. 

17*  receive  queue  length  -  number  of  data  octets  in  the  receive  queue. 

18.  receive  push  -  an  offset  from  the  front  of  the  receive  queue  indicating 
the  end  of  push  data. 

19-  receive  urgent  -  an  offset  from  the  front  of  the  receive  queue  indicating 
the  end  of  urgent  data. 

20.  receive  allocation  -  the  number  of  data  octets  the  local  ULP  is  currently 
willing  to  receive. 

A  state  machine's  initial  state  is  CLOSED  with  NULL  values  for  all  other  state 

vector  elements. 


3-2.4  Data  Structures 

For  clarity  in  the  events  and  actions  section,  data  structures  are  declared 
for  the  interaction  primitives  and  their  parameters.  A  subset  of  ADA  data 
constructs,  common  to  most  high  level  languages,  is  used.  However,  a  data 
structure  may  be  partially  typed  or  completely  untyped  where  specific  formats 
or  data  types  are  implementation  dependent. 

3.2.4. 1  state  vector  The  definition  of  the  TCP  service  machine  state  vector 
appears  in  Section  3-2.3  above.  The  service  machine  state  vectors  for  the  two 
local  TCP  service  machines  are  declared  as: 

sv_A  :  state_vector_type; 

sv_B  :  state_vector_type; 

type  state_vector_type  i s 
record 

state  :  (  CLOSED,  ACTIVE  OPEN,  PASSIVE  OPEN, 

ESTABLISHED,  CLOSING  ) ; 
source_addr  :  address_type; 
source_port  :  TW0_0CTETS; 
dest i nat i on_addr  :  address_type; 
destination  port  :  TW0_0CTETS; 
lcn  :  lcn_type; 
sec  :  secur i ty_type; 
or igi nal_prec  :  0. .7; 
actual_prec  :  0..7; 
ulp_timeout  :  time_type; 
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open_mode  :  (UNPASSIVE,  FULLPASSIVE,  ACTIVE); 
send_queue  :  t imed_queue_type; 
send_queue_l ength  :  integer; 
send_push  :  integer; 
send_urg  :  integer; 
recv_queue  :  queue_type; 
recv_queue_l ength  :  integer; 
recv_push  :  integer; 
recv_urg  .  integer; 
re>.v_al  ioc  :  integer; 
end  record; 

type  timed_queue_type  J_s  queue  (I  - .SI ZE_OF_SEND_RE SOURCE)  of 
record 

data_octet  ;  OCTET; 
timestamp  :  time_type; 
end  record; 

type  queue_type  j_s  queue  (1 . .S I ZE_QF_RECV_RESOURCE)  of 
data_octet  :  OCTET; 
end  record; 

type  address_type  is  F0UR_0CTETS; 

type  lcn_type  :  undefined;  — implementation  dependent 
type  time_type  :  undefined;  --implementation  dependent 

subtype  OCTET  is  INTEGER  range  0..255. 
subtype  TW0_0CTETS  is  INTEGER  range  0.. 2**1 6-1 
subtype  F0UR_0CTETS  is  INTEGER  range  0.. 2**32- 1; 


3. 2. 4. 2  from  ULP  The  from_ULP  structure  holds  the  interface  parameters  and 
data  associated  with  the  service  request  primitives  specified  in  Section  3-1  - 1 
above.  Although  the  structure  is  composed  of  the  parameters  from  all  the  ser¬ 
vice  requests,  a  particular  service  request  will  use  only  those  structure  ele¬ 
ments  corresponding  to  its  specified  parameters.  This  structure  directly 
corresponds  to  the  from_ULP  structure  declared  in  entity  state  machine  specif¬ 
ication,  Section  6. 3. 4. 2. 

The  from_ULP  structure  is  declared  as; 

type  f rom_ULP_type  i s 
record 

request_name  :  (Unspec i f i ed_Pass i ve_0pen,  Ful l_Pass i ve_0pen, 
Active_Open,  Active_Open_wi th_data. 

Send,  Allocate,  Close,  Abort,  Status); 

source_addr 
source_port 
desti nation_addr 
destination_port 
1  cn 

timeout 


1 
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precedence 
secur i ty 
data 

data_1 ength 
push_f 1 ag 
urgent_f 1 ag 
end  record; 

3- 2. It. 3  to  ULP  The  to_ULP  structure  holds  interface  parameters  and  data 
associated  with  the  service  response  primitives,  as  specified  in  Section  3.1.2 
above.  Although  the  structure  is  composed  of  the  parameters  from  all  the  ser¬ 
vice  requests,  a  particular  service  response  will  use  only  those  structure 
elements  corresponding  to  its  specified  parameters.  This  structure  directly 
corresponds  to  the  to_ULP  structure  declared  in  Section  6. 3.4. 3  of  the  mechan¬ 
ism  specification.  The  to_ULP  structure  is  declared  as: 

type  to_ULP_type  i s 
record 

service_response  :  (Open_ld,  Open_Fail,  Open_Success , 

Deliver,  Status_Response,  Terminate, 

Error)  ; 

source_addr 

source_port 

dest i nat i on_addr 

des t i nat i on_por  t 

Icn 

data 

data_l ength 
urgent_f 1 ag 
error_desc 

status_block  :  status_block_type; 
end  record; 

type  status_block_type  i s 
record 

connect i on_state 
send_wi ndow 
receive_wi ndow 
amount_of_unacked_data 
amount_of_unrece i ved_data 
urgent_state 
precedence 
secur i ty 
timeout 
end  record ; 
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3.2.5  Event  List 

The  events  for  the  TCP  service  machine  are  drawn  form  the  service  request 
primitives  defined  in  Section  3*!.  I  above.  Optional  service  request  parame¬ 
ters  are  shown  in  brackets.  The  capitalized  list  of  parameters  represent  the 
actual  values  of  the  parameters  passed  by  the  service  primitive.  The  event 
list: 

1.  Unspecified  Passive  Open  (  SOURCE  PORT, 

[.TIMEOUT]  [.PRECEDENCE]  [.SECURITY]  ); 

2.  Full  Passive  Open  (  S0URCE_P0RT, 

OE ST  I  NAT  I 0N_P0RT ,  DESTINATION  ADDRESS, 

[.TIMEOUT]  [.PRECEDENCE]  [.SECURITY]  ); 

3.  Active  Open  (  S0URCE_P0RT, 

DEST I  NAT  I 0N_P0RT ,  DEST I  NAT  I ON_ADDRESS 
[.TIMEOUT]  I. PRECEDENCE]  [.SECURITY]  ); 

k.  Active  Open  w/data  (  S0URCE_P0RT, 

DEST I  NAT  I 0N_P0RT ,  DEST I  NAT  I ON_ADDRESS 
[.TIMEOUT]  [.PRECEDENCE]  [.SECURITY]  ); 

DATA.  OATA_LENGTH,  PUSH_F LAG ,  URGENT_FLAG  ); 

5.  Send  (  LCN ,  DATA,  DATA_LENGTH ,  PUSH_F LAG ,  URGENT_F LAG  [.TIMEOUT]  ); 

6.  Al locate  (  LCN,  DATA  LENGTH  ) 

7.  C 1 ose  (  LCN  ) 

8.  Abort  (  LCN  ) 

9.  Status  (  LCN  ) 

10.  NULL  -  Although  no  service  request  is  issued  by  a  ULP, 

certain  conditions  within  the  TCP  service  machine 
produce  a  service  response. 


1 
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3*2. b  Events  and  Actions 

For  the  purposes  of  this  definition,  the  ULP  and  TCP  entities  are  identified 
with  the  capitoi  letters  "A"  and  "B".  The  first  ULP  to  make  a  service  request 
is  labelled  ULP  "A";  its  local  service  machine  is  TCP  "A."  The  peer  ULP  and 
its  TCP  are  labelled  ULP  B  and  TCP  B.  The  service  requests  are  labelled  with 
the  identifier  of  the  issuing  ULP,  such  as  Close/A.  The  service  responses  are 
similarly  labelled,  such  as  Terminate/B. 

A  service  request  appearing  with  a  identifier  may  be  issued  by  either  ULP 
A  or  ULP  B.  The  appropriate  TCP  handles  the  request  updating  its  own  state 
vector  if  necessary.  The  service  response  corresponding  to  such  a  request  is 
directed  to  the  appropriate  ULP. 

When  a  service  request  is  invalid  for  the  current  state  of  the  state  machine, 
the  service  request  appears  without  a  parameter  list. 

In  this  service  machine  model,  "simultaneous"  service  are  treated  as  unordered 
sequential  events.  Hence,  CLOSE/A  occurring  "simultaneously"  with  CLOSE/B  is 
represented  as  occurring  sequentially  without  intervening  events.  The  order 
chosen  for  the  event  sequence  should  not  alter  the  resulting  state,  so  that  a 
sequence  such  as  (CLOSE/A,  CLOSE/B)  should  lead  to  the  same  state  as  the 
(CLOSE/B,  CLOSE/A)  sequence. 

The  STATUS  event  produces  the  same  service  response  from  the  TCP  service 
machine  in  every  state.  Rather  than  show  these  in  each  state,  the  STATUS 
request  and  STATUS  RESPONSE  response  are  shown  once  here. 

Event:  STATUS  (  LCN  ) 

Actions:  STATUS  RESPONSE (  LCN,  S0URCE_P0RT,  SOURCE  ADDRESS, 

destination'port,  DESTINATION_ADDRESS, 

PRECEDENCE.  SECURITY,  C0NNECTT0N_STATE , 

RECE I VE_WIND0W,  SEND_WIND0W, 

AM0UNT_WA I T I NG_ACK ,  AM0UNT_WA I T I NG_RECE I PT , 
URGENT~MODE ,  TIMEOUT  ); 

3.2.6. 1  Event/Actions  Spec i f i cat i ons  The  following  section  is  organized  by 
composite  state.  Mirror-image  composite  states,  such  as  PASSIVE/ACTIVE  and 
ACTIVE/PASSIVE,  appear  as  just  one.  Only  one-way  data  transfer  is  represented 
by  the  service  machine,  since  the  data  transfer  service  is  symmetric.  Thus, 
a  definition  of  bi-directional  data  transfer  can  be  provided  by  duplicating 
the  existing  one-way  definition. 

Certain  conditions  checks  and  groups  of  actions  occur  in  several  places  and 
have  been  formed  into  decision  functions  and  action  procedures.  The  decisions 
function  definitions  appear  in  Section  3-2. 6. 2.  The  action  procedure  defini¬ 
tions  appear  in  Section  3. 2. 6. 3. 
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STATE  A  -  CLOSED 
STATE  B  -  CLOSED 


Event:  Unspecified  Passive  Open/A  (  SOURCE_PORT  [.TIMEOUT] 

[.PRECEDENCE]  [.SECURITY]  ) 

Actions:  record_open_parameters (A ,  UNPASSIVE); 
sv_A.lcn  :»  ass i gn_new_l cn; 

open_id(  sv_A.lcn,  sv_a.source_port,  sv_A . source_addr ,  NULL,  NULL  ); 
TRANSFER  to_ULP  to  the  ULP  named  by  sv_A . source_por t ; 
sv  A. state  :*  PASSIVE  OPEN; 


Event:  Full  Passive  Open/A  (  SOURCE_PORT, 

DESTINATION  PORT,  DEST I  NAT  I ON_ADDRESS 
[.TIMEOUT]  [.PRECEDENCE]  [.SECURITY]  ) 

Actions:  record_open_parameters (A ,  FULLPASS I VE) ; 
sv_A.lcn  :*  ass i gn_new_lcn; 

open_id(  sv_A.lcn,  sv_A . source_por t ,  sv_A . source_addr , 

sv_A.destination_port,  sv_A.desti nation_addr)  ; 
TRANSFER  to_ULP  to  the  ULP  named  by  sv_A. source  port; 
sv_A. state  :=  PASSIVE  OPEN; 


Event:  Active  Open/A  (  SOURCE  PORT.  DESTINATION  PORT,  DEST I  NAT  I ON_ADDRESS 

[.TIMEOUT]  [,PRECEDENCE]~[, SECURITY]  ) 

Actions:  record_open_parameters (A,  ACTIVE); 
sv_A.!cn  :■  ass i gn_new_l cn; 

open_id(  sv_A.lcn,  sv_A.source_port,  sv_A . source_addr , 

sv_A .des t i nat i on_por t ,  sv_A .dest i nat i on_addr) ; 
TRANSFER  to_ULP  to  the  ULP  named  by  sv_A . source_por t ; 
sv_A. state  :*  ACTIVE_0PEN; 


Event:  Active  Open  with  data/A(  SOURCE_PQRT, 

DESTINATION  PORT,  DESTINATION  ADDRESS 
[.TIMEOUT]  I, PRECEDENCE]  [.SECURITY] 

DATA,  DATA_LENGTH ,  PUSH_FLAG,  URGENT_FLAG  ) 

Actions:  sv_A.lcn  :■  ass i gn_new^l cn; 

open_id(  sv_A.lcn,  sv__A.source_port,  sv_A .source_addr , 

sv_A.destination_port,  sv_A.destination_addr) ; 
TRANSFER  to_ULP  to  the  ULP  named  by  sv_A.source_port; 
if  (room_i n  (sv_A . send_queue) 
then 

add_to_send_quaue (sv_A)  ; 
record_open_parameters (A,  ACTIVE) ; 
sv_A. state  7-  ACTIVE  OPEN; 
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openf a i I  (  sv_A . 1 cn  ) ; 

TRANSFER  to  ULP  to  the  ULP  named  by  sv_A . source_por t ; 


Event:  Close/A  (  LCN  ) 

or  Abort/A  (  LCN  ) 

or  Allocate/A  (  LCN.  DATA_LENGTH  ); 

Actions:  error  (sv_A. Ion,  "Connection  does  not  exist."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_A.source_port; 
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STAT£_A  -  PASSIVE  OPEN 
STATE~B  »  CLOSED 


Event:  Close/A  (  LCN  ) 

or  Abort/A  {  LCN  ) 

Actions:  initial i ze  (  sv_A  ); 

sv_A. state  :*  CLOSED: 

Event:  Unspecified  Passive  Open/B  (•  SOURCE  PORT  [.TIMEOUT] 

[.PRECEDENCE]  [.SECURITY]  ) 

Actions:  sv_B.lcn  :=  ass i gn_new_l cn; 

record_open_parameters (B,  UNPASSIVE) ; 

open_id(  sv_B.lcn,  sv_B . source_por t ,  sv_B . source_addr ,  NULL,  NULL  ); 
TRANSFER  to_ULP  to  the  ULP  named  by  sv_B. source  port; 
sv_B. state  :=  PASS  I VE_0PEN ; 


Event:  Full  Passive  Open/B  (  S0URCE_P0RT, 

DESTINATION  PORT.  DEST I  NAT  I ON_ADDRESS 
[.TIMEOUT]  [.PRECEDENCE]  [.SECURITY]  ) 

Actions:  sv_B.lcn  :=  ass i gn_new_l cn; 

record_open_parameters (B,  FULLPASS I VE)  ; 

open_id(  sv_B.lcn,  sv_B.source_port,  sv_B . source_addr , 

sv_B .dest i nat i on_port ,  sv_B .dest i nat i on_addr  ); 
TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_por t ; 
sv_B. state  :■  PASS  I VE_0PEN; 


Event:  Active  Open/B (  S0URCE_P0RT,  DESTINATION  PORT,  DEST I  NAT  I ON_ADDRESS 
[.TIMEOUT]  [.PRECEDENCE]  [.SECURITY]  ) 

Actions:  record_open_parameters (B,  ACTIVE); 
sv_B.lcn  :-  ass i gn_new_lcn; 

open_id(  sv_B.lcn,  sv_B . source_por t ,  sv_B . source_addr , 

sv_B.destination_port,  sv_B. dest i nat ion_addr  ); 
TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_port; 
sv_B. state  7-  ACTIVE_OPEN; 


Event:  Active  Open  with  data/B(  S0URCE_P0RT, 

DESTINATION  PORT.  DESTINATION  ADDRESS 
[.TIMEOUT]  [.PRECEDENCE]  [.SECURITY] 

OATA,  DATA_LENGTH,  PUSH_FLAG,  URGENT_FLAG  ) 

Actions:  sv_B.lcn  :-  ass i gn_new_l cn; 

open_id{  sv_B.lcn,  sv_B . source_port ,  sv_B.source_addr , 


r 

1 

1. 
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sv_B .dest i nat i on_por t ,  sv_B .dest i nat i on_addr  ); 
TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_por t ; 
if  (room_i n (sv_B . send_queue) 
then 

add_to_send_queue (sv_B)  ; 
record_open_parameter s (B,  ACTIVE) ; 
sv_B. state  7-  ACTIVE_OPEN; 

else 

openf a i 1  (  sv_B . I cn  ) ; 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 

Event:  Allocate/A  (  LCN.  OAT  A_i ENGTH  ) 

Actions:  sv  A.recv  alloc  :*  sv  A.recv_alloc  +  DATA_LENGTH; 


Event:  Full  Passive  Open/A  (  ) 
or  Send/A  {  ) 

Actions:  er ror (sv_A . 1 cn ,  "Illegal  request."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_A . source_por t ; 


Event:  Close/B  (  ) 

or  Abort/B  (  ) 
or  Send/B  (  ) 
or  A 1 locate/B  (  ) 

Actions:  error  (sv_B. lcn,  "Illegal  request."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 
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STATE  A  =  ACTIVE  OPEN 
STATE'S  =  CLOSED 


Event:  Close/A  (  LCN  ) 

or  Abort/A  (  LCN  ) 

Actions:  initial i ze  (  sv_A  ); 

sv_A. state  :=  CLOSED; 


Event:  Allocate/A(  LCN,  OAT A_LENGTH  ) 

Actions:  sv_A.recv  alloc  :«  sv  A.recv  alloc  +  DATA  LENGTH; 


Event:  Send/A  (  LCN,  DATA,  DATA  LENGTH,  PUSH  FLAG,  URGENT  FLAG 
[.TIMEOUT]  ) 

Actions:  if  (room_in  (sv_A.send  queue)) 
then  if  (TIMEOUT  ! !-  NULL) 

then  sv_A.u!p_timeout  :**  TIMEOUT; 
add_to_send_queue (sv_A) ; 

else  error (sv_A . lcn,  "Insufficient  resources."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_A . source_por t ; 


Event:  Unspecified  Passive  Open/B  (  S0URCE_P0RT  [.TIMEDUT] 

[.PRECEDENCE]  [.SECURITY]  ) 

Actions:  sv_B.lcn  :»  ass i gn_new_l cn; 

record_open_parameters (B,  UNPASSIVE)  ; 

open_id(  sv_B.lcn,  sv_B .source_port,  sv_B.source_addr,  NULL,  NULL  ); 
TRANSFER  to  ULP  to  the  ULP  named  by  sv  B.source_port; 
sv_B. state  7-  PASS  I VE_0PEN; 


Event:  Full  Passive  Open/B  (  S0URCE_P0RT, 

DESTINATION  PORT,  DESTINATION  ADDRESS 
[.TIMEOUT]  I, PRECEDENCE]  [.SECURITY]  ) 

Actions:  sv_B.lcn  :*  ass i gn_new_l cn; 

record_open_parameters (B,  FULLPASSIVE) ; 

open_id(  sv_B.lcn,  sv_B.source_port,  sv_B . source_addr , 

sv_B.destination_port,  sv_B.dest i nat i on_addr  ); 
TRANSFER  to_ULP  to  the  ULP  named  by  sv  B. source  port; 
sv_8. state  7-  PASS  I VE_0PEN; 


Event:  Active  Open/B  (  S0URCE_P0RT, 

DESTI NAT  I 0N_P0RT,  DESTINATION  ADDRESS 


( 
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[.TIMEOUT]  [.PRECEDENCE]  [.SECURITY]  ) 

Actions:  sv_B.lcn  :=  ass i gn_new_l cn ; 

record_open_parameters (8 ,  ACTIVE)  ; 

open_id(  sv_B.lcn,  sv_B . sour ce_por t ,  sv_B . source_addr , 

sv_B.destination_port,  sv_B .dest i nat i on_addr  ); 
TRANSFER  to_ULP  to  the  ULP  named  by  sv_B. source  port; 
sv_B. state  7=  ACTIVE_OPEN; 


Event:  Active  Open  with  data/B{  S0URCE_P0RT, 

DEST I  NAT  I 0N_P0RT ,  DEST I  NAT  I ON_ADDRESS 
[.TIMEOUT]  [.PRECEDENCE]  [.SECURITY] 

DATA,  DATA_LENGTH,  PUSH_FLAG,  URGENT_FLAG  ) 

Actions:  sv_B.lcn  :=  ass i gn_new_l cn; 

open_id(  sv_B.lcn,  sv_B . source_por t ,  sv_B . source_addr , 

sv_B.destination_port,  sv_B .dest i nat i on_addr  ); 
TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 
if  (room_i n  (sv_B .send_queue) 
then  add_to_send_queue (sv_B) ; 

record_open_parameters {B,  ACTIVE) ; 
sv_B. state  :=  ACTIVE_OP£N; 

else  openfail(  sv_B.lcn  ); 

TRANSFER  to__ULP  to  the  ULP  named  by  sv_B . source_por t ; 


Event:  Full  Passive  Open/A {  ) 
or  Act i ve  Open/A  (  ) 
or  Active  Open  with  data/A  (  ) 

Actions:  error  (sv_A . 1 cn,  "Illegal  request."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_A.source_port; 


Event:  Send/B  (  ) 

or  Close/B  {  ) 
or  Abort/B  (  ) 

Actions:  error  (sv_B . 1 cn,  "Illegal  request."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_por t ; 

Event:  NULL 

Actions:  Internal  Events 

!)if  t imeout_exceeded  (sv_A) 
then  openfail(  sv_A.lcn); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_A . source_por t ; 
initial i 2e (  sv_A  )  ; 
sv_A. state  :*  CLOSED; 
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STATE  A  -  PASSIVE  OPEN 
STATE~B  -  ACTIVE  OPEN 


Event:  Close/*  (  LCN  ) 

or  Abort/*  (  LCN  ) 

Actions:  initial i z  e  (  sv_*  ); 

sv  *. state  :=  CL0SE0; 


Event:  Allocate/*(  LCN.  DAT A_LENGTH  ) 

Actions:  sv_* . recv_a I  I oc  :*  sv_* . recv_a 1 1 oc  +  DATA_LENGTH; 


Event:  Send/B  (  LCN,  DATA,  DATA  LENGTH,  PUSH  FLAG,  URGENT_F  LAG 
[.TIMEOUT]  ) 

Actions:  if  (room_i n (sv_B . send_queue) 
then 

add_to_send_queue (sv_B) ; 

if  (TIMEOUT  ! !-  NULL) 

then  sv_8.ulp_timeout  :*  TIMEOUT; 

el  se 

error  (  sv_B.lcn,  "Insufficient  resources."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_por t ; 


Event:  Send/A  (  ) 

Actions:  f -or  (sv_A . 1 cn ,  "Illegal  request."); 

Tn  “iSFER  to_ULP  to  the  ULP  named  by  sv_A .  source_port; 


Event:  Full  Passive  Open/*  (  ) 
or  Act i veOpen/*  (  ) 
or  Act i veOpen  with  data/*(  ) 

Actions:  error (sv_*. Icn,  "Illegal  request.'); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_*.source_port; 


Event:  NULL 

Actions:  Internal  Events 

1)  if  (sv_A.sec  !!■  sv_B.sec) 
then 

openf a i 1  (  sv_B .Icn  )  ; 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_port ; 
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initial i  ze  (  sv_B  )  ; 
sv_B. state  :  =  CLOSED; 


else  — Take  greater  precedence  level  to  model  precedence  negotiation; 
--If  negotiation  is  not  supported,  mismatched  precedence 
--is  handled  the  same  as  mismatched  security, 
if  (sv_A .or i g i na l_prec  !!=  sv_B .or i g i na l_prec) 
then 

sv_A . actua l_prec  :=  max imum (sv_A .or i g i na l_prec , 

sv_B .or i g i nal_prec) ; 

sv_B.actual_prec  :=  max i mum  (sv_A . or i g i na I _prec , 

sv_B .or i g i na l_prec) ; 

if  (sv_A .open_mode  =  UNPASSIVE) 
then 

sv_A .dest i nat i on_addr  :=  sv_B . source_addr ; 
sv_A .dest i nat i on_port  :=  sv_B . source_por t ; 


sv_A. state  :=  ESTABLISHED; 
open_success  (  sv_A.Ien  ); 
TRANSFER  to_ULP  to  the  ULP 
sv_B. state  :=  ESTABLISHED; 
open_success  (  sv_B.lcn  ); 
TRANSFER  to  ULP  to  the  ULP 


named  by  sv_A . source_por t ; 
named  by  sv_B . sour ce_por t ; 


OR, 

2)  if  t imeout_exceeded (sv_B) 
then 

openfai 1 (  sv_B. Icn  ) ; 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.lcn; 
initial i ze  (  sv_B  )  ; 
sv_8. state  :=  CLQSEO; 


i. 
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STATE_A 
STATE  B 


PASSIVE 

PASSIVE 


OPEN 

OPEN 


Event:  Allocate/*(  LCN ,  DATA_LENGTH  ) 

Actions:  sv_* . recv_a I  1 oc  :*  sv_*.recv_alloc  +  DATA_LENGTH; 

Event:  Close/*  (  LCN  ) 

or  Abort/*  (  LCN  ) 

Actions:  initial i ze  (  sv_* 

sv_*. state  :«  CLOSE*: , 


Event:  Full  Passive  Open/*  {  ) 
or  Act i veOpen/*  (  ) 
or  Acti veOpen  with  data/*(  ) 
or  Send/*  (  ) 

Actions:  error (sv_*. 1 cn,  "Illegal  request."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_*.source_port; 


> 
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STATE_A  -  ACTIVE  OPEN 
STATE~B  =  ACTIVE  OPEN 


Event:  A1 locate/*  (  LCN,  OATA_LENGTH  ) 

Actions:  sv  *.recv  alloc  :*  sv  *.recv  alloc  +  DATA  LENGTH; 


Event:  Close/*  (  LCN  ) 

or  Abort/*  {  LCN  ) 

Actions:  initial i ze  (  sv_*  ); 

sv_*. state  :*  CLOSED; 


Event:  Full  Passive  Open/*  (  ) 
or  Active  Open/*  (  ) 
or  Active  Open  with  data/*(  ) 

Actions:  error  (sv_*. Icn,  ”11  legal  request."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_* . source_por t ; 


Event:  Send/*  (  LCN,  DATA,  DAT A_LENGTH ,  PUSH_F LAG ,  URGENT_FLAG 
[.TIMEOUT]  ) 

Actions:  if  (room_in (sv_*. send_queue) 
then 

add_to  send  queue  (sv  *) ; 

i f  (TIMEOUT-! ! =  NULL~ 

then  sv_* .u 1 p_t i meout  : m  TIMEOUT; 

e  1  se 

error  (  sv_*.lcn,  "Insufficient  resources."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_*.source_port; 


Event:  NULL 

Actions:  Interna!  Events 

1)  if  (sv_A.sec  !!■  sv_B.sec) 
then 

openf a i 1  (  sv_A .Icn  ) ; 

Transfer  to_ULP  to  the  ULP  named  by  sv_A.source_port; 
openf a i 1 (  sv_B. Icn  ) ; 

Transfer  to_ULP  to  the  ULP  named  by  sv_B . source_port ; 
initial ize(  sv_A  );  sv_A. state  :«  CLOSED; 

initialize(  sv_B  );  sv_B. state  :■  CLOSED; 


else  — take  greater  precedence  level  to  model  precedence  negotiation; 
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--if  negotiation  not  supported,  mismatched  precedence 
--is  handled  just  as  mismatched  security 
if  (sv_A ,or i g i na l_prec  ! ! *  sv_B .or i g i na l_prec) 
then 

sv_A.actual_prec  :=  max imum  (sv_A .or i g i na l_prec , 

sv_B .or i gi na I _prec) ; 

sv_B.actual_prec  :*  max imum (sv_A .or i g i na l_prec , 

sv_B .or i g i na )_prec) ; 

sv  A. state  :*  ESTABLISHED; 
sv~B. state  :«  ESTABLISHED; 
open_success  (  sv_A.lcn  ); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_A . source_por t ; 
open_success (  sv_B.lcn  ); 

TRANSFER  to__ULP  to  the  ULP  named  by  sv_A.source_port; 


OR, 

2)  if  timeout_exceeded (sv_A) 
then 

openfail(  sv^A.lcn); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_A.source_port; 
initial i2e (sv_A) ; 
sv_A. state  :=  CLOSED; 

OR, 

3)  if  timeout_exceeded (sv_A) 
then 

openf a i 1 {  sv_B . 1 cn  )  ; 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_por t ; 
initial i ze  (  sv_B  ) ; 
sv  B. state  :■»  CLOSED; 
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STATE  A  -  ESTABLISHED 
STATE~B  -  ESTABLISHED 


Event:  Send/* (  LCN ,  DATA,  DATA  LENGTH.  PUSH_F LAG ,  URGENT_F LAG 
[.TIMEOUT]  ) 

Actions:  if  (room_in (sv_*.send_queue) 
add_to_send_queue (sv_*) ; 
if  (TIMEOUT-! !-  NULL~ 
then  sv_* . u 1 p_t i meout  :«  TIMEOUT: 

else 

error  (  sv_*.lcn,  "Insufficient  resources.11); 

TRANSFER  toJJLP  to  the  ULP  named  by  sv_*.source_port; 


Event:  A1 locate/* (  LCN,  OATAJ.ENGTH  ); 

Actions:  sv_*.recv_al loc  :*  sv_*.recv_al loc  +  DATA_LENGTH; 
if  (sv_*.recv_queue_length  >  0) 
then  try_to_de! i ver ; 


Event:  Abort/*  (  LCN  ) 

Actions:  terminate (sv_* . 1 cn ,  "User  abort."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_*.source_port; 
i ni t i a  I ize (  sv_*  ) ; 
sv  *. state  :*  CLOSED; 


Event:  Close/*  (  LCN  ) 

Actions:  sv_*. send_push  :*  sv_*. send_queue_l ength; 

sv  *. state  :-  CLOSING; 


Event:  Full  Passive  Open/*  (  ) 
or  Active  Open/*  (  ) 
or  Active  Open  with  data/*(  ) 

Actions:  error (sv_*. Icn,  "Illegal  request."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_*.source_port; 


Event:  NULL 

Actions:  Internal  Events 

— For  clarity,  one-way  data  transport,  from  TCP  A  to  TCP  B  is  shown. 
--Because  the  data  transport  service  is  symmetric,  the  following 
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—  text  could  be  duplicated  to  represent  bi-directional  data  transport. 

1 )  i f  t imeout_exceeded  (sv_A) 
then 

term i nate (sv_A . 1 cn,  "ULP  timeout."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_A . source_por t ; 
initial i ze (sv_A) ; 
sv_A. state  :*  CLOSED; 

OR. 

2)  i f  (conditions  exist  such  that  no  data  can  be  exchanged 

by  local  state  machines  ) 

then 

termi nate (sv_A. lcn,  "Service  failure."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_A.source_port; 
terminate (sv_B. lcn,  "Service  failure."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_por t ; 
i n i t i a  1 i 2e (sv_A) ;  sv_A. state  :«  CLOSED; 

ini ti al i ze  (sv  B) ;  sv_B. state  :=  CLOSED; 


OR. 

3) i f  (the  data  exchange  between  local  state  machines  is  triggered) 
then 

if  (sv_A . send_urg  ! !=  0) 
then 

sv_B.recv_urg  :*  (sv_B . recv_queue_l ength  +  sv_A . send_urg) ; 

Dequeue  some  portion  of  data  equal  to  "amount" 

(amount  may  be  >■  0)  from  sv_A . send_queue 
and  append  to  sv_B . recv_queue; 

i f  (amount  >  0) 
then 

sv_A . send_queue_l ength  :»  sv_A . send_queue_l ength  -  amount; 
sv_B . recv_queue_l ength  :*  sv_B . recv_queue_l ength  +  amount; 

if  (sv_A . send_urg  *<  amount) 
then  sv_A . send_urg  :*  0; 

else  sv_A . send_urg  :■  sv_A . send_urg  -  amount; 
if  (sv_A. send_push  ■<  amount) 

then  sv_B . recv_push  :»  sv_B . recv_push  +  sv_A . send_push ; 
sv_A.send_push  :=  0; 

else  sv_A . send_push  :*  sv_A . send_push  -  amount; 
try_to_del iver; 
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STATE  A  -  ESTABLISHED 
STATE~B  »  CLOSING 


Event:  Send/A (  LCN ,  DATA,  OAT A_L£NGTH ,  PUSH_F LAG ,  URGENT_F LAG 
[.TIMEOUT]  ) 

Actions:  if  (room_i n  (sv_A . send_queue) 
add_to_send_queue (sv_A)  ; 
i  f  (TIMEOUT  !  !-  NULL)" 
then  sv_A.ulp_timeout  :»  TIMEOUT; 

else 

error  (  sv_A.lcn,  "Insufficient  resources."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_A . source_por t ; 


Event:  Close/A  (  LCN  ) 

Actions:  sv_A . send_push  :*=  sv_A . send_queue_l ength ; 

sv  A. state  :*  CLOSING; 


Event:  A  I  locate/*  (  LCN,  OATAJ.  ENGTH  ); 

Actions:  sv_*.recv_al loc  :*  sv_* . recv_a 1 1 oc  +  DATA_LENGTH; 
if  (sv_*. recv_queue_l ength  >  0) 
then  try_to_del iver; 


Event:  Abort/*  (  LCN  ) 

Actions:  initial i ze  (  sv_*  ); 

sv_*. state  :=  CLOSED; 

terminate  (sv_*. Icn,  "User  abort."); 

TRANSFER  to_ULF  to  the  ULP  named  by  sv_* . source_port ; 


Event:  Send/B  (  ) 

or  Close/B(  ) 

Actions:  error (sv_B. Icn,  "Connection  closing."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 


Event:  Active  Open/*(  ) 

or  Active  Open  with  data/*(  ) 
or  Full  Passive  Open/* (  ) 

Actions:  error (sv_*. Icn,  "Illegal  request."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_*.source_port; 
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Event:  NULL 

Actions:  Internal  Events 

1)  i f  t imeout_exceeded  (sv_*) 
then 

termi  nate  (sv__*.  Icn,  "ULP  timeout."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_* . source_por t ; 
initial i ze (sv_*)  ; 
sv_*. state  :=  CLOSED; 

OR. 

2)  i f  (conditions  exist  such  that  no  data  can  be  exchanged 

by  local  state  machines  ) 

then 

termi nate  (sv_A . 1 cn,  "Service  failure."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_A . source_por t ; 
termi nate  (sv_8 . 1 cn,  "Service  failure."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 
i ni t i al i ze (sv_A) ;  sv_A. state  :»  CLOSED; 
i ni t i al i 2e (sv_B) ;  sv_B. state  :=  CLOSED; 

OR, 

3)  i f  (contents  sv_B . send_queue  have  all  been  transferred 

to  sv_A . recv_queue  and  subsequently  delivered  to  ULP  A  ) 

then 

c los i ng  (  sv_A . 1 cn  )  ; 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_A.source_port; 


OR, 

4) --For  clarity,  one-way  data  transport,  from  TCP  A  to  TCP  B  is  shown. 
--Because  the  data  transport  service  is  symmetric,  the  following 
— text  could  be  duplicated  to  represent  bi-directional  data  transport. 
--Note  that  TCP  B  is  still  responsible  to  reliably  transport  any 
— data  remaining  in  sv_B . send_queue . 

if  (the  data  exchange  between  local  state  machines  has  been  triggered) 
then 

if  (sv_A . send_urg  !!*>  0) 
then 

sv_B .  recv_urg  equal  (sv_B  .  recv_queue_!  ength  +  sv_A .  send_urg)  ; 

Dequeue  some  portion  of  data  equal  to  "amount" 

(amount  may  be  >■  0)  from  sv_A . send_queue 
and  append  to  sv_B.recv_queue; 

if  (amount  >  0) 
then 

sv_A . send_queue_l ength  :»  sv_A . send_queue_l ength  -  amount; 
sv_B . recv_queue_l ength  :»  sv_B . recv_queue_l ength  +  amount; 

if  (sv_A.send_urg  ■<  amount) 
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then  sv_A , send_urg  :■  0; 

else  sv_A.send_urg  :=  sv_A . send_urg  - 

if  (sv_A . send_push  ■<  amount) 
then  sv_B . recv_push  :■  sv_B . recv_push 
sv_A.send_push  : »  0; 
else  sv_A . send_push  :*  sv_A . send_push 
try_to_del iver; 


amount ; 

+  amount; 
-  amount; 


STATE_A  -  CLOSING 
STATE  B  *  CLOSING 


Event:  Abort/*  (  LCN  ) 

Actions:  ini tial ize  (sv_*)  ; 

sv_*. state  :*  CLOSED; 

terminate  (sv_*. Icn,  "User  Abort."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_*.source_por t; 


V 


Event:  Allocate/*  (  LCN.  DATA_LENGTH  ); 

Actions:  sv_*. recv_a I  I oc  :*  sv_*. recv_alloc  +  DATA_LENGTH; 
if  (sv_*. recv_queue_) ength  >  0) 
then  try_to_del iver ; 


Event:  Send/*  (  ) 

or  Close/*  (  ) 

Actions:  error (sv_*. Icn,  "Connection  closing."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_*.souree_port; 


Event:  Active  Open/*  (  ) 

or  Active  Open  with  data/*  (  ) 
or  Full  Passive  Open/*  (  ) 

Actions:  error  (sv_*. icn,  "Illegal  request."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_*.sowrce_port; 


Event:  NULL 

Actions:  Internal  Events 

1) — For  clarity,  one-way  data  transport,  from  TCP  A  to  TCP  B  is  shown. 
--Because  the  data  transport  service  is  symmetric,  the  following 
— text  could  be  duplicated  to  represent  bi-directional  data  transport. 
--Note  that  TCP  B  is  still  responsible  to  reliably  transport  any 
--data  remaining  in  sv_B.send_queue. 

if  (the  data  exchange  between  local  state  machines  has  been  triggered) 
then 

if  (sv_A.send_urg  M»  0) 
then 

sv_B.recv_urg  equal  :■  (sv_8 . recv_queue_l ength  +  sv_A.send_urg) ; 
Oequeue  some  portion  of  data  equal  to  "amount" 
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(amount  may  be  >■  0)  from  sv_A . send_queue 
and  append  to  sv_B . recv_queue; 

if  (amount  >  0) 
then 

sv_A . send_queue_l ength  :■  sv_A . send_queue_ I ength 
sv_B . recv_queue_l ength  :=  sv_B . recv_queue_l ength 

if  (sv_A . send_urg  ■<  amount) 
then  sv_A . send_urg  :*  0; 

else  sv_A . send_urg  :»  sv_A . send_urg  -  amount; 
if  (sv_A . send_push  ■*<  amount) 

then  sv_B . recv_push  :«  sv_B . recv_push  +  amount; 
sv_A .send_push  ;*  0; 

else  sv_A . send_push  :«  sv_A . send_push  -  amount; 
try_to_del iver; 


OR, 

2)  if  ((contents  sv_B . send_queue  have  all  been  transferred 

to  sv_A . recv_queue  and  subsequently  delivered  to  ULP 

6 

(contents  sv_A . send_queue  have  all  been  transferred 
to  sv_B . recv_queue  and  subsequently  delivered  to  ULP 

» 

then 

termi nate  (sv_A . 1 cn,  "Connection  closed."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_A . source_por t; 
termi nate  (sv_B. lcn,  "Connection  closed."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 
ini tial ize  (sv_A) ;  sv_A. state  :»  CLOSED; 

ini tial ize  (sv_B) ;  sv_B. state  :=  CLOSED; 

OR. 

3)  if  timeout_exceeded  (sv_>’<) 
then 

termi nate (sv_*. lcn,  "ULP  timeout."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_*. source_port; 
initialize (sv_*)  ; 
sv  *. state  :■  CLOSED; 


amount; 
amount ; 


) 

)) 
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--The  composite  states,  CLOSED/ESTABLISHED,  CLOSING/ESTABLISHED, 
--ACTIVE /ESTABLISHED,  ACTIVE/CLOSING,  PASSIVE/ESTABLISHED,  AND 
--PASSIVE/CLOSING,  are  reached  after  abnormal 
--connection  termination  caused  by  either  an  Abort  request  or 
— service  failure.  Because  the  service  request  lists  for  ULP  A 
— already  appear  in  other  states,  these  lists  are  referenced  rather 
--than  dupl i cated . 
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ST  ATE_A  =  CLOSED 
STATE~B  =  ESTABLISHED 


--ULP  A's  service  request  list  appears  in  the  CLOSED/CLOSED  state. 

Event:  Send/B  (  LCN ,  OATA,  DATA  LENGTH,  PUSH_FLAG ,  URGENT  FLAG 
[.TIMEOUT]  ) 

Actions:  if  (room_in  (sv_B. send  queue)) 
i f  (TIMEOUT  ! ! =  NULL) 
then  sv_B.ulp_timeout  :=  TIMEOUT; 
add_to_send_queue (sv_B) ; 

else 

error  (  sv_B.lcn,  "Insufficient  resources."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 


Event:  Allocate/B(  LCN,  DATA_L£NGTH  ); 

Actions:  sv_B.recv_al loc  :»  sv_B . recv_a 1 1 oc  +  DATA_LENGTH; 
if  (sv_B. recv_queue_l ength  >  0) 
then  try_to_del i ver ; 


Event:  Close/B(  LCN  ) 

Actions:  sv_B.push  :*  sv_B.send_queue__l ength; 
sv_B. state  :»  CLOSING; 


Event:  Abort/B(  LCN  ) 

Actions:  termi nate (sv_B . 1 cn ,  "User  abort."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_por t ; 
initialize  (sv_B) ; 
sv_B. state  :»  CLOSED; 


Event:  Full  Passive  Open/B  (  ) 

Active  Open/B  (  ) 

Active  Open  with  Data/B(  ) 

Actions:  error (sv_B . 1 cn,  "Illegal  request."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 


Event:  NULL 


Actions:  Internal  Events 
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1) termi na te  (sv_B . I cn,  "Remote  Abort."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_por t ; 
initial i ze  (sv_B) ; 
sv  B. state  :*  CLOSED; 


OR, 

2)  i f  t i meout_exceeded  (sv_B) 
then 

terminate  (sv_B. ten,  "User  timeout."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B .source_port; 
initial i ze  (sv_B) ; 
sv_B. state  :=  CLOSED; 


n 
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STAT£_A  =  CLOSED 
STATE  B  =  CLOSING 


--ULP  A's  service  request  list  appears  in  the  CLOSED/CLOSED  state. 
Event:  Abort/B(  LCN  ) 

Actions:  term i nate  (sv_B . 1 cn ,  "User  Abort."): 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 
initial i ze  (sv_8) : 
sv_B. state  :*  CLOSED; 


Event:  Allocate/B(  LCN,  DAT A_LENGTH  ); 

Actions:  sv_B . recv_a ) 1 oc  :=  sv_B . recv_a 1 1 oc  +  DATA_LENGTH; 

if  (sv_B . recv_queue_l ength  >  0)  then  try_to_del i ver ; 


Event:  Close/B(  LCN  ) 

or  Send/B (  LCN  ) 

Actions:  error  (  sv_B.lcn,  "Connection  closing."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_port; 


Event:  Full  Passive  Oran/B (  LCN  ) 

Active  Open/B (  LCN  ) 

Active  Open  with  Data/B  {  LCN  ) 

Actions:  error  (  sv_B.lcn,  "Illegal  request."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_por t ; 


Event:  NULL 

Actions:  Internal  Events 

1) terminate  (sv_B. Icn,  "Remote  Abort."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B .source_port; 
initialize (sv_B) ; 
sv  B. state  :«  CLOSED; 


2) i f  timeout_exceeded (sv_B) 
then 

termi nate (sv_B . 1 cn,  "User  timeout."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_port; 
initial i ze  (  sv_B  ) ; 
sv  B. state  :*  CLOSED; 
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STATE_A  -  ACTIVE 
STATE  B  -  ESTABLISHED 


--ULP  A's  service  request  list  appears  in  the  ACTIVE/CLOSED  state. 

Event:  Send/B  (  LCN,  DATA,  DATA_L£NGTH,  PUSH_F LAG ,  URGENT_FLAG 
[.TIMEOUT]  ) 

Actions:  if  (room  i n  (sv  B . send_queue) 
if  (TIMEOUT  ! ! =  NULL) 
then  sv_B .ul p_t imeout  :=  TIMEOUT; 
add_to_send_queue (sv_B) ; 

else 

error  (  sv_B.lcn,  "Insufficient  resources."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 


Event:  C)ose/B(  LCN  ) 

Actions:  sv_8.push  sv_B.send_queue_length; 
sv_B. state  :*>  CLOSING; 


Event:  Abort/B(  LCN  ) 

Actions:  terminate (sv_8. Icn,  "User  abort.”); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 
initialize  (sv_B) ; 
sv_B. state  :=  CLOSED; 


Event:  Allocate/B(  LCN,  QATA_LENGTH  ); 

Actions:  sv_B . recv_a 1  I oc  :=  sv_B . recv_a 11 oc  +  DATA_LENGTH; 
if  (sv_B . recv_queue_l ength  >  0) 
then  try_to_del iver; 


Event:  Full  Passive  Open/B  (  ) 

Active  Open/B  (  ) 

Active  Open  with  Data/B(  ) 

Actions:  er ror  (sv_B . 1 cn,  "Illegal  request."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_port ; 


Event:  NULL 


Actions:  Internal  Events 
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1)  t'.-minate  (sv_B.  ten,  “Remote  Abort."); 

TR.'k,AFER  to_ULP  to  the  ULP  named  by  sv_B .  source_port ; 
i  1. .  .  i  a  I  i  ze  (sv_B)  ; 
sv_B. state  :*=  CLOSED; 

OR, 

2)  if  timeout_exceeded (sv_B) 
then 

terminate  {sv_B.  Icn,  "User  timeout.11); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_por t ; 
initial i ze  (sv_B) ; 
sv_B. state  :*  CLOSED; 

OR, 

3)  if  timeout_exceeded (sv_A) 
then 

termi nate  (sv_A . 1 cn,  "User  timeout."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_A.source_port; 
initial i ze  (sv_A) ; 
sv_A. state  :=  CLOSED; 
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STATE  A  =  ACTIVE 
STATE~B  «  CLOSING 


— ULP  A's  service  request  list  appears  in  the  ACTIVE/CLOSED  state. 

Event:  Send/8  (  ) 

or  Close/B  (  ) 

Actions:  error (sv_8. Icn,  "Connection  closing."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_por t ; 


Event:  Allocate/B(  LCN ,  DATAJ.ENGTH  ); 

Actions:  sv_B . recv_a I  1 oc  :*  sv_B.recv_al loc  +  DATA_LENGTH; 
if  (sv_B . recv_queue_l ength  >  0) 
then  try_to_del iver; 


Event:  Abort/B(  LCN  ) 

Actions:  termi nate  (sv_B . 1 cn,  "User  abort."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 
initialize  (sv_B) ; 
sv  B. state  :»  CLOSED; 


Event:  Full  Passive  Open/B  (  ) 
or  Active  Open/B  (  ) 
or  Active  Open  with  Oata/B(  ) 

Actions:  error  (sv_B . I cn ,  "Illegal  request."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 


Event:  NULL 

Actions:  Internal  Events 

1)  termi nate (sv_B . 1 cn,  "Remote  Abort."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_por t ; 
initialize  (sv_B) ; 
sv_B. state  :*  CLOSED; 

OR, 

2)  if  timeout_exceeded  (sv_B) 
then 

termi nate  (sv_B . I cn,  "User  timeout."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 
initial i ze (sv  B) ; 
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sv  B. state  :*  CLOSED ; 


OR, 

3)  if  timeout_exceeded (sv_A) 
then 

termi  nate  (sv_A.  lcn,  "User  timeout.1'); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_A.source_port; 
initialize  (sv_A) ; 
sv  A. state  :*  CLOSED; 
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STATE  A  -  PASSIVE 
STATE'S  -  ESTABLISHED 


— ULP  A’s  request  list  appears  in  the  PASSIVE/CLOSED  state. 

Event:  Send/B  (  LCN ,  DATA,  DATA  LENGTH,  PUSH_F L AG ,  URGENT_FLAG 
[, TIMEOUT]  ) 

Actions:  if  (room_i n (sv_B . send_queue) 
i f  (TIMEOUT  ! ! *  NULL) 
then  sv_B . u I p_t i meout  :=  TIMEOUT; 
add_to_send_queue (sv_B) ; 

else 

error  (  sv_B.!cn,  "Insufficient  resources."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 


Event:  CIose/B(  LCN  ) 

Actions:  sv_B.push  sv_B . send_queue_l ength ; 
sv_B. state  :*  CLOSING; 


Event:  Abort/B(  LCN  ) 

Actions:  terminate  (sv_B. Icn,  "User  abort."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_port ; 
initial i ze  (sv_8) ; 
sv_B. state  :■  CLOSED; 


Event:  Allocate/B{  LCN,  DATA_LENGTH  )  ; 

Actions:  sv_B . recv_a 1 1 oc  :■  sv_B.recv_alloc  +  DATA_LENGTH ; 
if  (sv_B . recv_queue_l ength  >  0) 
then  try_to_del iver; 


Event:  NULL 

Actions:  Internal  Events 

1)  term! nate (sv_B . 1 cn,  "Remote  Abort."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 
initial i ze  (sv_B) ; 
sv  B. state  :■  CLOSED; 


OR, 

2)  if  t imeout_exceeded  (sv_B) 
then 
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pT 


termi nate  (sv_B . I cn,  "User  timeout."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv  B. source  port; 
initial i ze  (sv_B) ; 
sv_B. state  :*  CLOSED; 
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STATE  A  -  PASSIVE 
STATE_B  -  CLOSING 


— ULP  A's  request  list  appears  in  the  PASSIVE/CLOSED  state. 
Event:  Allocate/B(  LCN,  DATA_L£NGTH  ); 

Actions:  sv_B . recv_a 1 1 oc  :*  sv_B . recv_a 1 1 oc  +  DATA_LENGTH; 
if  (sv_B . recv_queue_l ength  >  0) 
then  try_to_del i ver ; 


Event:  Abort/B(  LCN  ) 

Actions:  termi nate  (sv_B . I cn,  "User  abort."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 
initial i2e  (sv_8) ; 
sv_B. state  :«  CLOSED; 


Event:  Close/B(  LCN  ) 

or  Send/B  (  LCN  ) 

Actions:  error  (  sv_B.lcn,  "Connection  closing,"); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 


Event:  Full  Passive  Open/B (  LCN  ) 
or  Active  Open/B  (  LCN  ) 
or  Active  Open  with  Data/B  (  LCN  ) 

Actions:  error  (  sv_B.lcn,  "Illegal  request."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 


Event:  NULL 

Actions:  Internal  Events 

1)  termi nate (sv_B . I cn,  "Remote  Abort."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B . source_por t ; 
initial i ze  (sv_B) ; 
sv_B. state  :*  CLOSED; 

OR, 

2)  if  timeout_exceeded (sv_B) 

then  termi nate  (sv_B. lcn,  "User  timeout."); 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_B.source_port; 
initialize  (sv_B) ; 
sv_B. state  CLOSED; 
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3- 2. 6. 2  Dec i s i on  Funct i ons  The  decision  functions  represent  condition  checks 
made  in  several  places  in  the  service  state  machine  definition. 

3. 2. 6. 2.1  room  in(  state  vector  name  );  The  room_in  decision  function  com¬ 
pares  the  amount  of  space  available  in  the  send_queue  of  the  state_vector 
(named  by  the  parameter)  against  the  amount  of  data  provided  by  the  ULP  in  an 
Active  Open  with  Data  or  a  Send  service  request. 

The  data  effects  of  this  function  are: 

-  Data  examined: 

f r om_ULP.dat a_l ength  S I ZE_OF_SEND_RESOURCES 

sv_*.send_queue_l ength 

-  Return  values: 

FALSE  -  The  send_queue  cannot  accommodate  all  the  data 
provided  in  the  service  request. 

TRUE  -  There  is  enough  room  in  the  send_queue  for  the  data. 

if  (f rom_ULP.data_length  > 

(  S I ZE_OF_SENO_RESOURCE  -  sv_* . send_queue_l ength) 
then  return  (  FALSE  ) 
else  return  (  TRUE  ) : 


3. 2. 6. 2. 2  timeout  exceeded  (  sv  *  );  The  t i meout_exceeded  decision  function 
compares  the  current  time  against  the  age  of  the  data  in  the  send_queue  and 
the  specified  ULP  timeout  limit  to  determine  if  the  ULP  timeout  has  been 
exceeded . 

The  data  effects  of  this  function  are: 


-  Data  examined:  sv_*.ulp_timeout 


sv_*.send_queue 


Return  values: 

FALSE  -  The  data  in  the  send_queue  does  not  exceed  the  ULP 
defined  timeout  limit. 

TRUE  -  Data  in  the  send_queue  has  exceeded  the  timeout  limit. 


--The  data  at  the  front  of  the  queue  is  the  oldest. 


if  (sv_*.send_queue_l ength  >  0) 

then  if  (  CURRENT_TIME  >  sv_* . send_queue [0]  +  sv_*.ul p_timeout  ) 
then  return  (TRUE) 
else  return (FALSE)  ; 
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3. 2. 6. 3  Act i on  Procedures  These  routines  appear  in  several  places  in  the 
service  machine  definition.  The  can  be  replace  by  either  A  or  B  for 
delivery  to  the  appropriate  ULP. 

3. 2. 6. 3-1  add  to  send  queue  (  sv  *  )  The  add_to_send_queue  actions  procedure 
enqueues  the  data  provided  in  an  Active  Open  with  Data  or  Send  request  onto 
the  send_queue  of  the  state  vector  named  by  parameter. 

The  data  effects  of  this  procedure  are: 


-  Data  examined: 

f rom_ULP .da ta  f  rom_ULP  >urgent_f 1 ag 

f rom_ULP .da ta_l eng th  f rom_ULP . push_f 1 ag 


-  Data  modi f ied: 

sv_* .send_queue  sv_*. send_push 

sv_* . send_queue_l ength  sv_* . send_urg 


--Add  the  data,  urgent  and  push  information  provided  by  the  ULP 
—  in  a  SEND  to  the  send_queue  of  the  state  vector. 


Enqueue  contents  of  f rom_ULP .data  to  sv_* . send_queue,  stamping  each 
data  octet  with  the  current  time; 

sv_*.send_queue_I ength  :»  sv_*.send_queue_l ength  +  from_ULP .data_l ength ; 

if  (f rom_ULP .push_f 1 ag  *  TRUE) 

then  sv_*.send_push  :■  sv_* . send_queue_l ength ; 

if  (f romJJLP .urgent_f 1 ag  =  TRUE) 

then  sv_*.send_urg  sv_* . send_queue_l ength ; 

3. 2. 6. 3. 2  assign  new  len  The  ass i gn_new_l cn  action  procedure  assigns  a  local 
connection  name  not  currently  used  for  a  new  open  request  and  subsequent  con¬ 
nection. 

The  data  effects  of  this  procedure  are: 

-  Data  examined:  internal  resources 

-  Data  modified:  none 

— The  procedure  returns  the  value  to  be  used  as  the  new 
--local  connection  name. 


I 


K-4 


6  July  1982 


-59- 


System  Development  Corporation 
TM-7 172/1*82/00 


3. 2. 6. 3*3  error  {  local  connection  name,  error  description)  The  error  action 
procedure  copies  the  local  connection  name  and  error  description  text  supplied 
by  parameter  into  the  to_ULP  structure.  The  service  response  field  is 
assigned  to  ERROR  for  subsequent  transfer  to  the  ULP. 

The  data  effects  of  the  procedure  are: 

-  Data  examined:  procedure  parameters 

-  Date  modified:  to_ULP.lcn  to_ULP .error_desc 

to_ULP.Icn  local_connection_name; 
to_ULP.error_desc  :■  error_descr i pt ion; 
to_ULP.service_response  :*  ERROR; 

3. 2. 6. 3.1*  initialize  (sv  *) ;  The  initialize  action  procedure  clears  all 
values  of  the  state  vector  named  by  parameter. 

The  data  effects  of  this  procedure  are: 

-  Data  examined:  procedure  parameter 

-  Data  modified:  all  fields  of  sv_* 

dequeue (sv_* . send_queue , sv_* . send_queue_l ength) ; 
dequeue (sv_* . recv_queue , sv_* . r ecv_queue_l ength) ; 
sv  *  :**  null  state  vector; 


3-2. 6. 3.5  open  fail  (local  connection  name)  The  open_fai 1  action  procedure 
copies  the  local  connection  name  supplied  by  parameter,  and  the  0PEN_FAIL  ser¬ 
vice  response  into  the  to_ULP  structure  for  subsequent  transfer  to  the  ULP. 

The  data  effects  of  this  procedure  are: 

-  Data  examined:  procedure  parameter 

-  Data  modified:  to_ULP.lcn  to_ULP.service_response 

to_ULP.lcn  :*  local_connection_name; 
to_ULP.service_response  :-  0PEN_FAIL; 
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3. 2. 6. 3. 6  open  idQocal  connection  name,  source  port,  source  address. 
destination  port,  destination  addr)  The  open_id  action  procedure  copies  the 
parameters  and  the  0PEN_ID  service  response  into  the  to_ULP  structure  for  sub¬ 
sequent  transfer  to  the  ULP. 

The  data  effects  of  this  procedure  are: 

-  Data  examined:  procedure  parameters 

-  Data  modi f ied: 

to_ULP . 1 cn 
to_ULP . source_por  t 
to_ULP. source_addr 

to_ULP . I cn  :=  local_connection_name; 
to_ULP . source_por t  :=  source_port; 
to_ULP . source_addr  :=  sour ce_address ; 
to_ULP.destination_port  :=  dest i nation_port; 
to_ULP .dest i nat ion_addr  :=  destination_addr; 
to_ULP.service_response  :=  0PEN_ID; 

3-2. 6. 3-7  open  success  (local  connection  name)  The  open_success  action  pro¬ 
cedure  copies  the  local  connection  name  supplied  by  parameter,  and  the 
0PEN_SUCCESS  service  response  into  the  to_ULP  structure  for  subsequent 
transfer  to  the  UtP. 

The  data  effects  of  this  procedure  are: 

-  Data  examined:  procedure  parameter 

-  Data  modified:  to_ULP.lcn  to_ULP . serv i ce_response 

to_ULP.lcn  : ■  local_connection_name; 
to_ULP . serv i ce_response  :*  OPEN_SUCCESS ; 


to_ULP . servi ce_response 
to_ULP .dest i nat i on_port 
to  ULP .dest i nat i on  addr 


3-2.6. 3-8  term i nate ( 1  oca  1  connection  name,  descr i pt i on)  The  terminate  action 
procedure  copies  the  local  connection  name  and  description  supplied  by  parame¬ 
ter,  and  the  TERMINATE  service  response  into  the  to_ULP  structure  for  subse¬ 
quent  transfer  to  the  ULP. 

The  data  effects  of  this  procedure  are: 

-  Data  examined:  procedure  parameters 

-  Data  mod i f i ed : 

to_ULP . servi ce_response  to_ULP . 1 cn 

to_ULP .error_descr i pt i on 

to_ULP.lcn  :■  local_connect ion_name; 

T0_ULP .error_desc  :■  description; 

to_ULP . servi ce_response  :■  TERMINATE; 


i 
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3. 2. 6. 3-9  record  open  parameters  {  ULP  i dent i f i er ,  open  mode  )  The 
record_open_parameters  action  procedure  copies  the  values  provided  by  the  ULP 
in  an  open  request  to  the  state  vector. 

The  data  effects  of  this  procedure  are: 

-  Data  examined: 

f rom_ULP . source_port 
f rom_ULP. source_addr 
f rom_ULP . timeout 

-  Data  modi f ied: 

sv_*.source_port  •  sv_* . or i g i na l_prec 

sv_* .source_addr  sv_* .secur i ty 

sv_*.desti nation_port  sv_*. timeout 

sv_*.desti nation_addr  sv_*.open_mode 

— Record  the  socket-pair  and  connection  information 
— provided  in  the  open  service  request  in  the  state_vector . 

sv_*.port  :=  f rom_ULP.source_port; 
sv_*.addr  :*  the  address  of  this  TCP; 
sv_*.open_mode  :*■  open_mode; 

--Record  timeout,  security,  and  precedence  for  ULP  * 

--if  provided,  otherwise  assign  default  values; 

if  (f rom_ULP . secur i ty  ! i *  NULL) 
then  sv_*. secur i ty  :*=  from_ULP . secur  i  ty 
else  sv_*.  secur  i  ty  :=*  DEF AULT_S£CUR I TY; 

if  (from_ULP .precedence  ! !*  NULL) 
then  sv_*.or i g i na l_prec  :*=  from^ULP. precedence 
else  sv_*.or i g i na l_prec  :«=  DEF AULT_PRECEDENCE ; 

if  (from_ULP. timeout  ! !*  NULL) 
then  sv_*.ulp_t imeout  :•  from_ULP. timeout 
else  sv_*. u I p_t imeout  :■  DEFAULT_TI MEOUT; 

if  (sv_*.open_mode  !!“  UNPASSIVE) 

then  sv_*.destination_port  :■  f rom_ULP .des t i nat ion_por t; 

sv_* .dest i nat i on_addr  :■  f rom_ULP .dest i nat ion_addr ; 
else  sv_*.destination_port  :■  NULL; 
sv  *. dest i nat i on_addr  :■  NULL; 


f rom_ULP . precedence 
f rom_ULP . secur i ty 
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3-2.6.3-IO  try  to  del iver  The  try_to_de 1 i ver  action  procedure  determines 
from  the  receive  allocation,  the  receive  queue  size,  and  the  receive  push  and 
urgent  variables  how  much  data  to  deliver  to  the  local  ULP.  This  procedure  is 
called  from  several  places  for  both  ULP  A  and  ULP  B  in  the  service  machine 
definition.  Where  the  sv_*  notation  is  used,  the  appropriate  state  vector 
name  should  be  replaced. 

The  data  effects  of  this  procedure  are: 

-  Data  examined:  sv_*.source_port 

-  Data  mod i f i ed : 

to_ULP .data 
to_UL P. da ta_l ength 
to_ULP.urgent_f 1 ag 
to_ULP . 1 cn 
sv_* . recv_queue 

— The  amount  of  data  delivered  is  based  on  the  amount  of  pushed 
--data  waiting  and  the  receive  allocation. 

if  (sv_*.recv_push  !!=  0) 

then  --As  much  pushed  data  allowed  by  the  recv  allocation 
—  is  deli vered . 

if  (sv_*. recv_alloc  >  sv_* . recv_push) 
then 

to_ULP.data_length  :■  sv__* . recv_push ; 
sv_* . recv_push  :=  0; 

else 

to_ULP.data_length  :=  sv__* . recv_a  1  1  oc ; 
sv_*.recv_push  :■*  sv_* . recv_push  -  to_ULP.data_length; 

else  --Without  a  PUSH,  there  is  no  guarantee  of  delivery. 

— Deliver  some  amount  of  data  less  than  or  equal  to  receive 
— allocation  (possibly  none). 

to_ULP.data_length  :*  some  value; 

if  (to_ULP.data_!ength  !!•  0) 

then  --Update  state  vector  elements  and  prepare  data  and 
— and  parameters  for  delivery. 
toJJLP.Icn  :-  sv_*.lcn; 

— Urgent  data  cannot  be  delivered  followed  by  non-urgent  data. 

--If  "end-of-urgent"  falls  in  data  to  be  delivered,  make 
— two  separate  deliveries, 
if  ( (sv_* . recv_urg  !!■  0)  and 

(sv_*.recv_urg  <  to_ULP .data_iength)) 
then  begin 

--Deliver  urgent  data  alone, 
save  :»  to_ULP.data_length; 
to_ULP.data_length  :■  sv_*. recv_urg; 


sv_*. recv_push 
sv_*.recv_urg 
sv_*.recv_a 1 loc 
sv_* . recv_queue_l ength 
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sv_* . recv_urg  :=  0; 
to_ULP .urgent_f 1 ag  :=  false: 

Dequeue  to_l)LP.data_length  octets  from  sv_* . recv_queue 
and  place  in  to_ULP.data; 

sv_*.recv_al loc  :=  sv_*.recv_al loc  -  to_ULP.data_length; 
sv_*. recv_queue_! ength  :=  sv_* . recv_queue_l ength  - 

to_ULP .da ta_ length; 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_*.source_port; 

--Prepare  to  deliver  remaining  non-urgent  data. 

to_ULP ,data_! ength  :=  save; 

end; 

--If  urgent  data  follows  the  data  being  delivered,  inform  ULP. 

if  (sv_* . recv_urg  >  to_ULP .data_l ength) 

then 

to_ULP .urgen t_f 1 ag  :*  TRUE; 

sv_*.  recv_urg  :*  sv_* .  recv_urg  -  to_ULP.d?£a  Jength; 

else 

to_ULP .urgent_f 1 ag  :*  FALSE; 
sv_*. recv_urg  :*  0; 

Dequeue  to_ULP -data_l ength  octets  from  sv_* . recv_queue 
and  place  in  to_ULP.data; 

sv_*.recv_al loc  :=  sv_*.recv_al loc  -  to_ULP.data_length; 
sv_*. recv_queue_l ength  ;=  sv_*.recv_queue_length  - 

to_ULP .data_l ength ; 

TRANSFER  to_ULP  to  the  ULP  named  by  sv_*.source_port; 
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4.  SERVICES  REQUIRED  FROH  LOWER  LAYER 

This  section  describes  the  minimum  set  of  services  required  of  the  network 
layer  protocol  by  TCP. 

The  services  required  are: 

o  data  transfer  service 

o  generalized  network  service 

o  error  reporting  service 

A  description  of  each  service  follows. 

4 • 1  Data  Transfer  Service 

The  lower  layer  protocol  must  provide  data  transfer  between  TCP  modules  in  a 
communication  system.  Such  a  system  may  consist  of  a  single  network  or  a  set 
of  interconnected  networks  forming  an  internet.  Data  must  arrive  at  a  desti¬ 
nation  with  non-2ero  probability;  some  data  loss  may  occur.  The  data  transfer 
service  is  not  required  to  preserve  the  order  in  which  portions  of  data  are 
supplied  by  the  source  upon  delivery  at  the  destination.  Data  delivered  is 
not  necessarily  error-free. 

The  lower  layer  protocol  must  provide  data  transfer  throughout  the  system. 
TCP  need  only  supply  global  addressing  and  control  information  with  each  por¬ 
tion  of  data  to  be  delivered.  Routing  and  network  specific  characteristics 
are  handled  by  the  network  layer  protocol.  For  example,  TCP  need  not  be  aware 
of  current  topology  or  packet  size  restrictions  to  transmit  segments  through  a 
particular  network. 

4.2  Generalized  Network  Service 


The  lower  layer  protocol  must  provide  a  means  for  TCP  to  select  from  the 
transmission  service  qualities  provided  by  the  communication  syster  for  each 
portion  of  data  delivered.  The  transmission  quality  parameters  must  include 
precedence.  Also,  the  lower  layer  protocol  must  provide  a  means  of  labelling 
each  pr-tion  of  data  with  security  information  including  security  level,  com- 
partmentat ion,  handling  restrictions,  and  transmission  control  code  (i.e., 
closed  user  groups)  . 

4.3  Error  Reporting  Service 

The  lower  layer  protocol  must  provide  error  reports  to  TCP  indicating  discon¬ 
tinuation  of  the  above  services  caused  by  catastrophic  conditions  in  this  or 
lower  layer  protocols. 
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5-  LOWER  LAYER  SERVICE/INTERFACE  SPECIFICATIONS 

This  section  specifies  the  minimal  subnetwork  protocol  services  required  by 
TCP  and  the  interface  through  which  those  services  are  accessed.  The  first 
part  defines  the  interaction  primitives  and  their  parameters  for  the  lower 
interface.  The  second  part  contains  the  abstract  machine  specification  of  the 
lower  layer  services  and  interaction  discipline. 

5.1  INTERACTION  PRIMITIVES 

An  interaction  primitive  defines  the  purpose  and  content  of  information 
exchanged  between  two  protocol  layers.  Two  kinds  of  primitives,  based  on  the 
direction  of  information  flow,  are  defined.  Service  requests  pass  information 
downward;  service  responses  pass  information  upward.  These  primitives  need 
not  occur  in  pairs,  nor  in  a  synchronous  manner.  That  is,  a  request  does  not 
necessarily  elicit  a  "response";  a  "response"  may  occur  independently  of  a 
request. 

"i  he  information  associated  with  an  interaction  primitive  falls  into  two 
categories:  parameters  and  data.  The  parameters  describe  the  data  and  indi¬ 
cate  how  the  data  is  to  be  treated.  The  data  is  not  examined  or  modified. 
The  format  of  interaction  primitive  information  is  implementation  dependent 
and  so  is  not  specified. 

A  given  TCP  implementation  may  have  slightly  different  interfaces  imposed  by 
the  nature  of  the  network  or  execution  environment.  Under  such  c i rcums tances , 
the  primitives  can  be  modified  to  include  more  parameters  or  additional  primi¬ 
tives  can  be  defined.  However,  all  TCPs  must  provide  at  least  the  irj*  'ace 
specified  below  to  guarantee  that  all  TCP  implementations  can  support  S3me 
protocol  hierarchy. 


5.1.1  Service  Request  Primitives 

A  single  service  request  primitive  is  required  from  the  network  protocol, 
NET_SEND . 

5-1  .1.1  NET  SEND  The  NET_SEND  primitive  contains  complete  control  informa¬ 
tion  for  each  unit  of  data  to  be  delivered.  TCP  passes  in  a  NET_SEND  at  least 
the  following  information: 

o  source  address  -  address  of  TCP  sending  data 

o  dest i nat i on  address  -  address  of  the  TCP  to  receive  data 

o  protocol  -  identifier  assigned  to  recipient  TCP 

0  tvPe  2l  serv i ce  i nd i cators  -  relative  transmission  quality  associated 
wi th  unit  of  data 

-  precedence  -  one  of  eight  levels  :  (P0,  PI,  P2,  P3,  P4 ,  P5.  P6,  P7  ) 
where  P0  <»  PI  <-  P2  <-  P3  <”  PL  <-  P5  <«  P6  <■  P7 
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-  reliability  -  one  of  two  levels  :  (RO,  Rl)  where  RO  *  normal  relia¬ 
bility  and  Rl  =  high  reliability. 

-  delay  -  one  of  two  levels  :  (DO,  Dl)  where  DO ’=  normal  delay  and  D1 
*>  low  delay. 

-  throughput  -  one  of  two  levels  :  (TO,  Tl)  where  TO  =  normal 
throughput  and  Tl  =  high  throughput. 

o  i dent i f i er  -  value  distinguishing  this  portion  of  data  from  others  sent 
by  this  ULP. 

o  don ' t  fragment  i nd i cator  -  flag  showing  whether  the  network  protocol  can 
fragment  data  to  accomplish  delivery 

o  t i me  to  1 i ve  -  value  in  seconds  indicating  maximum  lifetime  of  data 
within  the  network 


o  data  I ength  -  length  of  data  being  transmitted 

o  opt i on  data  -  options  requested  by  TCP  from  those  supported  by  network 
protocol  including  at  least  security  labelling.  (The  Internet  Protocol 
supports  security  labelling,  source  routing,  return  routing,  stream  iden¬ 
tification,  and  time  stampi ng[8] .) 

o  data  -  present  when  data  length  is  greater  than  zero. 

5.1.2  Service  Response  Primitives 

A  single  service  response  primitive,  DELIVER,  is  required  of  the  network 
del ivery  service. 


5. 1.2.1  NET  DELIVER  The  NET_DEL I VER 
source  TCP  in  a  NET_SEND,  along 
option  information.  TCP  receives  in  a 
i nformat i on: 


primitive  contains  the  data  passed  by  a 
with  addressing,  quality  of  service,  and 
NET_DELIVER  at  least  the  following 


o  source  address  -  address  of  sending  TCP 
o  destination  address  -  address  of  the  recipient  TCP 

0  protocol  -  identifier  assigned  to  TCP  as  supplied  by  the  sending  TCP 

o  type  of  serv i ce  i nd i cators  -  relative  transmission  quality  associated 
wi th  unit  of  data 

-  precedence  -  one  of  eight  levels  :  (PO,  PI,  P2,  P3.  P**,  P5.  P6.  p7  ) 

where  PO  <-  PI  <*  P2  <*  P3  <■  PA  <■  P5  <-  P6  <-  P 7 

-  reliability  -  one  of  two  levels  :  (RO,  Rl)  where  RO  *  normal  relia¬ 
bility  and  Rl  ■  high  reliability. 
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-  delay  -  one  of  two  levels  :  (DO,  Dl)  where  DO  *  normal  delay  and  D1 
“  low  delay. 

-  throughput  -  one  of  two  levels  :  (TO,  Tl)  where  TO  -  normal 
throughput  and  Tl  =  high  throughput. 

o  data  1 enqth  -  length  of  received  data  (possibly  zero) 

o  option  data  -  options  requested  by  source  TCP  as  supported  by  the  network 
including  at  least  security  labelling.  (The  Internet  Protocol  supports 
security  labelling,  source  routing,  return  routing,  stream  identifica¬ 
tion,  and  time  stamping  options[8].) 

o  data  -  present  when  data  length  is  greater  than  zero. 

In  addition,  a  NET_D£LIVER  may  contain  error  reports  from  the  network  protocol 
either  together  with  parameters  and  data  listed  above,  or,  independently  of 
that  information.  The  detail.s  of  the  error  reports  are  network  dependent. 


5-2  EXTENDED  STATE  MACHINE  SPECIFICATION  OF  SERVICES  REQUIRED  FROM  LOWER 
LAYER 


The  extended  state  machine  in  this  section  defines  the  behavior  of  the  entire 
network  protocol  service  machine  from  the  perspective  of  TCP.  This  service 
machine  is  modelled  as  a  "black  box"  whose  internal  actions  are  hidden  from 
the  TCPs  using  the  network  protocol's  services.  The  TCP-pair  provides 
stimuli,  in  the  form  of  service  requests,  and  receives  the  resulting  network 
protocol  reactions,  in  the  form  of  service  responses. 

An  abstract  machine  definition  is  composed  of  a  machine  identifier,  a  state 
diagram,  a  state  vector,  a  set  of  data  structures,  an  event  list,  and  an 
events  and  actions  correspondence. 

5.2.1  Machine  Instantiation  Identifier 

Each  upper  interface  state  machine  is  uniquely  identified  by  the  four  interac¬ 
tion  primitive  parameters: 

o  source  address 

o  destination  address 

o  protocol 

o  identifier 

One  state  machine  instance  exists  for  the  NET_SEND  and  NET_DELIVER  primitives 
whose  parameters  carry  the  same  values. 
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5.2.2  State  Diagram 

The  upper  interface  state  machine  has  a  single  state  which  never  changes.  No 
diagram  is  needed. 

5.2.3  State  Vector 

The  upper  interface  state  machine  has  a  single  state  which  never  changes.  No 
state  vector  is  needed. 


5*2.1.  Data  Structures 

For  clarity  in  the  events  and  actions  section,  data  structures  are  declared 
for  the  interaction  primitives  and  their  parameters.  A  subset  of  ADA  data 
constructs,  common  to  most  high  level  languages,  is  used.  However,  a  data 
structure  may  be  partially  typed  or  completely  untyped  where  specific  formats 
or  data  types  are  implementation  dependent. 

5-2.1*.!  to  NET  The  to_NET  structure  holds  the  interface  parameters  and  data 
associated  with  the  NET__S£ND  primitive  specified  above.  This  structure 
directly  corresponds  to  the  to_NET  structure  declared  in  Section  6. 3. 4. 4  of 
the  mechanism  definition.  The  to_NET  structure  is  declared  as: 

type  to_NET_type  i s 
record 

source_addr 
dest i nat i on_addr 
protocol 

type_of_service  *  s 
record 

precedence 
re! iabi I i ty 
delay 
throughput 
end  record: 
identi f ier 
time_to_l i ve 
dont_f ragment 
length 
data 
options 
end  record; 


5. 2. 4. 2  from  NET  The  from_NET  structure  holds  interface  parameters  and  data 
associated  with  the  NET_DELIVER  primitive,  as  specified  in  Section  5*1.2 
above.  This  structure  directly  corresponds  to  the  from_NET  structure  declared 
in  Section  6. 3. 4. 5  of  the  mechanism  definition.  The  from_NET  structure  is 
declared  as: 

type  f rom_NET_type  i s 
record 


source  addr 
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dest  i nat i on_addr 
protocol 

type_of_serv i ce  i s 
record 

precedence 

reliability 

delay 

throughput 
end  record; 
length 
data 
opt  ions 
error 

end  record; 


5.2.5  Event  List 

The  events  are  drawn  from  the  interaction  primitives  specified  in  Section  5.1 
above.  An  event  is  composed  of  a  service  request  primitive  and  an  abstract 
timestamp  to  indicate  the  time  of  event  initiation.  The  event  list; 

1.  NET_SEND  (  to_NET  )  at  time  t 

2.  NULL  -  Although  no  service  request  is  issued  by  TCP,  certain  conditions 
within  network  layer  or  lower  layers  produce  a  service  response.  These 
conditions  can  include  duplication  of  data  and  subnet  errors. 


5.2.6  Events  and  Actions 

The  following  section  defines  the  set  of  possible  actions  elicited  by  each 
event . 


EVENT  ■  NET_SEND  (  to_NET  )  at  time  t 
Act i ons : 

1.  NET_0EL I VER  from_NET  at  time  t+N  to  TCP 

at  destination  to_NET.destination_addr  with  all  of 
the  following  properties; 

a.  The  time  elapsed  during  data  transmission  satisfies 
the  time-to-live  limit,  i .e.  N  <-  to_NET.time_to_l ive. 

b.  The  quality  of  data  transmission  is  at  least 
equal  to  the  relative  levels  specified  by 
to_NET . type_of _serv ice. 

c.  if  (to_NET.dont_f ragment  *  TRUE) 

then  network  layer  fragmentation  has  not  occurred 
i n  trans i t . 
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d.  if  (to_NET. opt  ions  includes  loose  source  routing) 
then  f rom_NET .data  has  visited  in  transit  at  least 
the  gateways  named  by  the  source  provided  by  NET_SEND. 

e.  if  (to_NET. options  includes  strict  source  routing) 
then  f rom_NET.data  has  visited  in  transit  only 

the  gateways  named  by  source  route  provided  by  NET_SEND. 

f.  if  (to_N£T .opt i ons  includes  record  routing) 
then  the  list  of  nodes  visited  in  transit  is 
delivered  in  from_NET. 

g.  if  (to_NET. opt  ions  includes  security  labelling) 
then  the  security  label  is  delivered  in  from_NET. 

h.  if  (to_NET. options  includes  stream  identifier) 

then  the  stream  identifier  is  delivered  in  from_NET. 

i.  if  (to_NET. options  includes  internet  timestamp) 

then  the  internet  timestamp  is  delivered  in  from_NET. 

OR. 

2.  NET_DELIVER  to  TCP  source  to_N£T . source_addr  indicating 
one  of  the  following  error  conditions: 

a.  destination  to_NET.dest i nat i on_addr  unreachable 

b.  protocol  to_NET. protocol  unreachable 

c.  if  (to_NET.dont_f ragment  »  TRUE) 

then  fragmentation  needed  but  prohibited 

d.  if  (to_NET. opt  ions  contains  any  option) 
then  parameter  problem  with  option. 

OR, 

3.  no  action 


EVENT  -  NULL 
Actions: 

1.  NET_DELIVER  to  TCP  at  source  to_NET . source_addr 
indicating  the  following  error  condition: 

a.  error  conditions  in  network  or  lower  layers 

OR, 

2.  NET_OELIVER  from  NET  at  time  t+N  to  TCP  at  destination 


i 
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to_NET .des t i nat i on_addr  with  all  of  the  following  properties: 

a.  i'he  time  elapsed  during  data  transmission  satisfies 

the  time-to-live  limit,  i .e.  N  <=  from_NET.time_to_l ive. 

b.  The  quality  of  data  transmission  is  at  least 
equal  to  the  relative  levels  specified  by 

f rom_NET. type_of _serv i ce . 

c.  if  (f rom_NET,dont_f ragment  *  TRUE) 

then  network  layer  fragmentation  has  not  occurred 
in  transit. 

d.  if  (from_NET. options  includes  loose  source  routing) 
then  to_NET.data  has  visited  in  transit  at  least 

the  gateways  named  by  the  source  provided  by  NET_SEND. 

e.  if  (f rom_NET.opt ions  includes  strict  source  routing) 
then  to_NET.data  has  visited  in  transit  only 

the  gateways  named  by  source  route  provided  by  NET_SEND. 

f.  if  (f rom_NET .opt i ons  includes  record  routing) 
then  the  list  of  nodes  visited  in  transit  is 
delivered  in  to_NET. 

g.  if  (f rom_NET.opti ons  includes  security  labelling) 
then  the  security  label  is  delivered  in  to_NET. 

h.  if  (from_NET. opt  ions  includes  stream  identifier) 
then  the  stream  identifier  is  delivered  in  to_NET. 

i.  if  (f rom_NET.opt i ons  includes  internet  timestamp) 
then  the  internet  timestamp  is  delivered  in  to_NET. 
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6.  TCP  ENTITY  SPECIFICATION 


This  section  defines  the  mechanisms  of  each  TCP  entity  supporting  the  services 
provided  by  the  TCP  service  machine.  The  first  subsection  motivates  the 
specific  mechanisms  chosen  and  discusses  the  underlying  philosophy  of  those 
choices.  The  second  subsection  defines  the  format  and  use  of  the  TCP  segment 
header  fields.  The  last  subsection  specifies  an  extended  state  machine 
representation  of  the  TCP  entity. 


6.1  OVERVIEW  OF  TCP  MECHANISMS 

The  TCP  mechanisms  are  motivated  by  TCP  services,  described  in  Section  2: 
o  multiplexing  service 
o  connection  management  services 
o  data  transport  service 
o  error  reporting  service 

Each  service  could  be  supported  by  any  of  several  mechanisms.  The  selection 
of  mechanisms  is  guided  by  design  standards  including  simplicity,  generality, 
flexibility,  and  efficiency.  The  mechanism  descriptions  identify  the  service 
or  services  supported  and  explain  how  the  mechanisms  work. 

This  overview  begins  with  an  introduction  to  some  basic  terminology  used 
throughout  the  TCP  entity  mechanisms  discussions.  The  mechanisms  present  in  a 
TCP  enti ty  are: 

flow  control  windows 

duplicate  and  out-of-order  data  detection 

positive  acknowledgements  with  retransmission 

checksum 

push 

urgent 

ULP  timeout 

security  and  precedence 

mul ti-addressi ng 

passive  and  active  open  requests 

three-way  handshake  for  SYN  exchange 

open  request  matching 

three-way  handshake  for  FIN  exchange 

resets 


6.1.1  Background  and  Terminology 

This  section  presents  the  terminology  used  in  the  mechanism  descriptions.  The 
concept  of  sequence  numbers  and  sequence  space,  the  variables  maintained  in  a 
state  vector  (defined  in  Section  6.3.^-D  and  segment  header  fields  (defined 
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in  Section  6.2)  are  introduced.  Also  presented  is  a  list  of  the  states  within 
the  TCP  state  machine  (defined  in  Section  6.3). 

6. 1.1.1  Sequence  Numbers  A  fundamental  notion  in  the  design  of  the  TCP 
entity  is  that  every  octet  of  data  sent  over  a  connection  has  a  sequence 
number.  These  sequence  numbers  are  used  by  several  mechanisms  (data  ordering, 
duplicate  detection,  positive  acknowledgement  with  retransmission,  and  flow 
control  windows)  to  provide  reliable,  ordered  data  transfer. 

The  sequence  number  carried  in  a  TCP  header  is  a  four  octet  value  designating 
the  sequence  number  of  the  first  octet  of  data  in  the  segment.  Each  succes¬ 
sive  data  octet  is  numbered  sequentially.  Thus,  each  segment  is  bound  to  as 
many  consecutive  sequence  numbers  as  there  are  octets  of  data  in  the  segment. 

The  numbering  scheme  is  extended  to  include  certain  control  information  as 
well.  This  is  achieved  by  implicitly  including  some  control  flags  in  the 
sequence  space  so  they  can  reliably  transmitted  without  confusion  (i.e.,  one 
and  only  one  copy  of  the  control  will  be  acted  upon).  Control  information  is 
not  physically  carried  in  the  segment  data  space.  Consequently,  we  must  adopt 
rules  for  implicitly  assigning  sequence  numbers  to  control.  The  "SYN"  and 
"FIN"  flags  are  the  only  controls  requiring  this  protection.  These  controls 
are  used  only  at  connection  opening  and  closing.  For  sequence  number  pur¬ 
poses,  the  "SYN"  is  considered  to  occur  before  the  first  actual  data  octet  of 
the  segment  in  which  it  occurs.  When  a  "SYN"  is  present  then  SEG.StQ  is  the 
sequence  number  of  the  "SYN."  The  FIN  is  considered  to  occur  after  the  last 
actual  data  octet  in  a  segment  in  which  it  occurs.  The  segment  length 
(LENGTH)  includes  both  data  and  sequence  space  occupying  controls. 

It  is  essentia!  to  remember  that  the  actual  sequence  number  space,  ranging 
from  0  to  2**32— 1 .  is  finite  though  very  large.  Because  the  space  is  finite, 
all  arithmetic  dealing  with  sequence  numbers  must  be  performed  modulo  2**32. 
This  unsigned  arithmetic  preserves  the  relationship  of  sequence  numbers  as 
they  wrap  around  from  2**32- 1  to  0  again. 

6. 1.1. 2  Connect i on  Sequence  Var i ab 1 es  To  maintain  a  connection,  a  TCP  entity 
records  and  updates  connection  status  information  in  a  state  vector.  (This  is 
also  called  a  Transmission  Control  Block,  or  TCB.)  Among  the  status  informa¬ 
tion  stored  in  the  state  vector  are  sequence  variables  describing  the  data 
exchange  over  the  connection.  A  connection  carries  data  in  two  directions, 
and  so  each  TCP  entity  maintains  sequence  variables  for  both  the  data  it  sends 
and  the  data  it  receives. 

Send  Var i abl es  Send  variables  are  used  to  track  the  status  of  the  send  data 
stream  with  regard  to  acknowledgements,  urgent  data,  pushed  data,  window  size 
and  position,  and  the  initial  sequence  number.  This  list  is  a  subset  of  the 
complete  list  of  all  send  variables  c'  aring  in  the  state  vector  definition. 
Section  6.3.3. 

1.  SEND_NEXT  -  send  next,  the  sequence  number  of  the  next  octet  of  data  to 
be  sent 
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2. 

SENDJJNA  -  send  unacknowledged,  all  octets 
sequence  number  have  been  acknowledged. 

up  to  but 

not 

i  nc 1 ud i ng 

th  i  s 

3- 

SEND_WNDW  -  send  window,  the  number  of  data  octets  currently  allowed 
be  sent  relative  to  SEND_UNA. 

to 

4. 

SEND_URG  -  send  urgent  point,  the  sequence 
urgent  data. 

number  of 

the 

last  octet 

of 

5- 

SEN0_PUSH  -  send  push  point,  the  sequence 
pushed  data. 

number  of 

the 

last  octet 

of 

6. 

SEND_LASTUP1  -  last  window  update  one,  the  sequence 
incoming  segment  used  for  last  window  update. 

number 

carried  by 

the 

7. 

SEN0_LASTUP2  -  last  window  update  two,  the  acknowledgement 
by  the  incoming  segment  used  for  last  window  update. 

number  carried 

8. 

SEND_lSN  -  initial  send  sequence  number, 
sent  on  this  connection. 

the  sequence  number  of  the 

SYN 

These  names  correspond  to  the  state  vector  elements  defined  in  Section  6.3.3. 

Send  Sequence  Space  If  the  space  of  send  sequence  numbers  is  pictured  as  a 
number  line,  the  following  diagram  shows  the  relationships  among  some  of  the 
variables  defined  above. 


12  34 


SENOJJNA  SEN0_NEXT  SENDJJNA 

+  SEND_WNDW 

1  -  old  sequence  numbers  which  have  been  acknowledged 

2  -  sequence  numbers  of  sent  but  as  yet  unacknowledged  data 

3  -  sequence  numbers  allowed  for  new  data  transmission 

(i .e.  the  unused  send  window) 

4  -  future  sequence  numbers  which  are  not  yet  allowed 


Receive  Var i ab 1 es  The  receive  variables  track  the  receive  data  stream  in 
regard  to  acknowledgements,  urgent  data,  pushed  data,  window  sire  and  posi¬ 
tion,  and  initial  sequence  number.  These  variables  are  a  subset  of  the  state 
vector  elements  defined  in  Section  6.3*3* 

1.  RECV_NEXT  -  receive  next,  the  sequence  number  of  the  next  data  octet  to 
be  received. 

2.  RECV_WNDW  -  the  number  of  data  octets  that  can  currently  be  received 
starting  from  RECV_NEXT. 
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3.  RECV_URG  -  receive  urgent  point,  the  sequence  number  of  the  last  octet  of 
urgent  data. 

4.  RECV_PUSH  -  receive  push  point,  the  sequence  number  of  the  last  octet  of 
pushed  data. 

5.  RECV_ISN  -  initial  rece i ve  •  sequence  number,  the  sequence  number  of  the 
SYN  received  from  the  remote  TCP. 

Rece i ve  Sequence  Space  If  the  space  of  receive  sequence  numbers  is  pictured  as 
a  number  line,  the  following  diagram  shows  the  relationships  among  some  of  the 
variables  defined  above. 


1  2  3 


RECV_NEXT  RECV_NEXT 

+  RECV_WNDW 

1  -  old  sequence  numbers  which  have  already  been  accepted 

2  -  sequence  numbers  allowed  to  be  received 

(i.e.,  the  receive  window) 

3  -  future  sequence  numbers  not  yet  allowed 

6. 1.1. 3  Current  Segment  Var i abl es  TCP  entities  communicate  in  units  of 
exchange  called  segments.  A  segment  is  made  up  of  a  header,  containing 
addressing  and  control  information,  and  a  text  area,  containing  a  portion  of 
the  send  or  receive  data  streams.  A  formal  definition  of  the  segment  header 
format  appears  in  Section  6.2.  The  following  header  fields  and  related  values 
are  used  in  the  mechanism  descriptions. 


1.  SEG.SEQ  -  segment  sequence  number,  the  sequence  number  carried  in  the 
segment  header.  It  may  number  the  first  octet  of  carried  data,  number  a 
sequence  control  flag,  or  (in  an  empty  segment)  indicate  the  next  octet 
to  be  sent. 

2.  SEG.ACK  -  segment  acknowledgement  number,  the  acknowledgement  from  the 
sending  TCP.  That  is,  the  next  sequence  number  expected  from  the  receiv¬ 
ing  TCP. 

3.  SEG.WNDW  -  segment  window,  the  current  number  of  octets  that  the  sending 
TCP  will  accept  as  counted  from  SEG.ACK. 

4.  SEG.URGPTR  -  segment  urgent  pointer,  the  number  of  data  octets  remaining 
before  the  end  of  the  urgent  data,  as  counted  from  SEG.SEQ. 

5-  PRECEDENCE  -  segment  precedence  level,  supplied  as  a  service  response 
parameter . 

6.  LENGTH  -  segment  length,  number  of  octets  of  header  and  text  carried  in 
the  segment.  This  value  is  supplied  as  a  service  response  parameter. 
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6. 1.1. 4  Connect i on  States  A  TCP  connection  progresses  through  three  phases: 
opening  (or  synchron i zat i on) ,  maintenance,  and  closing.  The  three  phases  are 
broken  down  further  into  states  which  represent  significant  stages  in  the 
handshake  mechanisms  of  connection  opening  and  closing.  These  states 
correspond  to  the  values  assumed  by  the  primary  element  of  the  state  vector 
structure,  sv. state.  The  TCP  entity  states  are: 

1.  LISTEN  -  after  a  passive  open  request  from  the  local  ~~UlP,  represents 
waiting  for  a  connection  request  from  a  remote  TCP  (in  the  form  of  a  SYN 
segment) . 

2.  SYN_SENT  -  after  an  active  open  request  from  the  local  ULP  and  having 
sent  an  open  request  (i.e.,  a  SYN),  represents  waiting  for  a  matching 
connection  open  request  (i.e.,  another  SYN)  from  the  remote  TCP. 

3.  SYN_RECEIVED  -  represents  waiting  for  a  confirming  connection  request 
acknowledgement  (i.e.,  the  ACK  of  the  SYN)  after  having  both  received  and 
sent  connection  requests, 

4.  ESTABLISHED  -  represents  an  open  connection  on  which  data  can  be  passed 
between  ULPs  in  both  directions. 

5.  FIN_WAIT1  -  after  a  close  service  request  from  the  local  ULP,  represents 
waiting  for  either  a  close  request  (in  the  form  of  a  FIN  segment)  from 
the  remote  TCP,  or  an  acknowledgement  of  the  close  request  already  sent 
(i.e.,  an  ACK  of  the  FIN).  Data  received  from  remote  TCP  is  delivered  to 
the  local  ULP. 

6.  FIN_WAIT2  -  represents  waiting  for  a  connection  termination  request 
(i.e.,  a  FIN)  from  the  remote  TCP.  Data  received  from  remote  TCP  is 
delivered  to  the  local  ULP. 

7.  CLOSE_WAIT  -  represents  having  received  a  connection  close  request  (i.e., 
a  FIN)  from  the  remote  TCP  and  waiting  for  a  connection  close  request 
from  the  local  ULP.  Data  sent  by  the  local  ULP  is  sent  to  the  remote 
TCP. 

8.  LAST_ACK  -  represents  having  both  sent  and  received  a  connection  close 
request,  having  acknowledged  the  remote  close  request,  and  waiting  for 
the  last  acknowledgment  from  the  remote  TCP. 

9.  CLOSING  -  represents  waiting  for  the  acknowledgement  of  a  connection 
close  request  (i.e.,  an  ACK  of  the  FIN)  from  the  remote  TCP. 

10.  TIME_WAIT  -  represents  waiting  for  enough  time  to  pass  to  ensure  the 
remote  TCP  has  received  the  acknowledgement  of  its  connection  close 
request. 

11.  CL0SE0  -  represents  no  connection. 

The  full  definition  of  the  TCP  states,  events,  and  processing  appears  in  Sec¬ 
tion  6.3. 
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6.1.2  Flow  Control  Window 

TCP  provides  a  flow  control  mechanism,  called  a  window,  to  enable  a  receiving 
TCP  entity  to  govern  the  amount  of  data  transmitted  by  a  sending  TCP  entity. 
A  window  is  an  "absolute1'  flow  control  technique.  Absolute  flow  control 
defines  an  interval  nf  sequence  numbers  corresponding  to  the  amount  of  data  an 
entity  is  willing  to  accept.  This  technique  prevents  ambiguity  introduced  by 
duplicate  segments  because  permission  to  transmit  is  specified  as  a  specific 
range  of  sequence  numbers  rather  than  an  incremental  value. 

The  receiving  TCP  maintains  the  amount  of  data  allowed  for  acceptance  in  the 
receive  variable  RECV_WNDW.  This  value  is  bound  to  the  receive  sequence  space 
beginning  at  RECV_N£XT,  the  next  expected  data  octet.  A  TCP  entity  communi¬ 
cates  its  current  receive  window  to  the  remote  TCP  by  placing  the  window  in 
each  outbound  segment  header  in  the  following  manner.  The  window  field  of  the 
segment  header,  SEG. WINDOW,  is  a  positive  integer  value  expressing  the  number 
of  acceptable  data  octets.  The  acknowledgement  number  in  the  segment  header, 
SEG.ACK,  associates  that  quantity  to  the  receive  sequence  space.  Thus,  the 
receive  window  starts  with  SEG.ACK  and  continues  through  the  number  of  octets 
indicated  by  SEG. WINDOW. 

As  each  incoming  segment  is  validated  by  sequence  number  and  acknowledgement 
(Sections  6.1.3  and  6.1.k),  the  TCP  entity  records  the  window  size  in  the  send 
variable,  SEND_WNDW. 

6. 1.2.1  Shr i nk i nq  Wi ndows  A  TCP  entity  is‘strongly  discouraged  from  "shrink¬ 
ing"  its  receive  window.  A  window  is  said  to  shrink  when  a  TCP  entity  adver¬ 
tises  a  large  window  and  subsequently  advertises  a  smaller  one  without  having 
accepted  the  difference  in  data.  Such  behavior  complicates  the  send  data 
algorithms  of  the  peer  entity.  For  example,  a  sending  TCP  may  act  upon  a 
large  window  allocation  by  sending  all  of  the  advertised  amount.  When  the 
window  shrinks,  data  already  sent  becomes  outside  the  window.  The  sender  must 
either  set  back  the  send  variables  and  remove  data  from  the  retransmission 
queue  to  "un-send"  the  data,  or  else  ignore  the  smaller  window.  The  robust¬ 
ness  principle  mandates  that  although  a  TCP  entity  does  not  shrink  its  own 
receive  window,  it  will  be  prepared  for  such  behavior  by  other  entities. 

6. 1.2. 2  Zero  Wi ndows  Windows  can  close,  that  is  become  zero  in  length,  when 
a  receiving  TCP  has  no  more  room  to  receive  data,  either  because  the  ULP  has 
stopped  accepting  or  because  system  resources  have  been  temporarily  exhausted. 
In  this  situation,  the  sending  TCP  normally  would  not  send  data.  And,  if  no 
data  is  generated  by  the  other  UIP,  the  sending  entity  will  receive  no  new 
window  updates.  Without  special  mechanisms,  zero  windows  could  halt  data 
transfer . 

With  a  zero  send  window,  a  sending  TCP  must  be  prepared  to  accept  from  the 
local  and  send  to  the  remote  TCP  at  least  one  octet  of  new  data.  Also,  a 
sending  TCP  must  transmit  segments  at  regular  intervals  into  the  zero  window 
in  order  to  guarantee  that  the  re-opening  of  the  receive  window  will  be  reli¬ 
ably  reported.  The  recommended  transmission  interval  in  this  situation  is  two 
minutes . 


With  a  zero  receive  window,  a  TCP  entity  receiving  a  segment  with  data  must 
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still  send  an  acknowledgement  showing  its  next  expected  sequence  number  and 
current  window  even  though  it  does  not  accept  the  data.  If  the  receiving  TCP 
emits  an  empty  ACK  segment  when  opening  its  receive  window,  it  may  resume 
receiving  data  more  quickly. 

Even  with  a  zero  receive  window,  a  TCP  must  process  the  ACK,  RST,  and  URG 
fields  of  all  acceptable  incoming  segments. 

6. 1.2. 3  Wi ndow  Updates  w i th  One-way  Data  F 1 ow  In  a  connection  with  data 
flowing  primarily  in  one  direction,  the  window  information  will  be  carried  in 
segments  marked  with  the  same  sequence  number.  If  such  segments  arrive  out- 
of-order,  they  cannot  be  reordered.  This  situation  is  not  serious,  but  it 
does  allow  the  window  information  to  occasionally  be  based  on  old  reports  from 
the  receiver. 

A  strategy  to  avoid  this  problem  is  to  check  both  the  sequence  number  and  the 
acknowledgement  number  when  deciding  to  update  the  send  window.  That  is,  use 
the  window  information  from  segments  carrying  either  a  higher  sequence  number 
than  previously  seen,  or  the  same  sequence  number  and  the  highest  acknowledge¬ 
ment  number.  The  highest  sequence  number  of  an  incoming  segment  used  for  a 
window  update  is  recorded  in  the  send  variable  S£ND_L ASTUP 1 ;  the  highest  ack¬ 
nowledgement  number  in  SEN0_LASTUP2 . 


6. 1.2. 4  Window  Management  Suggestions  A  TCP  entity's  method  of  r staging  its 
window  has  significant  influence  on  performance.  The  following  sections  dis¬ 
cuss  certain  window  management  policies  and  their  effects. 

Wi ndow  S i ze  vs.  Actua 1  Capac i ty  In  general,  advertised  window  size  is  based 
on  the  amount  of  available  receive  storage.  Although  indicating  large  windows 
encourages  transmissions,  false  window  promises  can  degrade  performance.  If 
the  window  is  larger  than  actual  storage  capacity,  more  data  may  arrive  than 
can  be  accepted.  The  excess  data  is  discarded,  causing  its  retransmission, 
adding  unnecessarily  to  the  .oad  on  the  communications  system  and  the  sending 
TCP. 

Sma 1 1  Wi ndows  Allocating  very  small  windows  causes  data  to  be  transmitted  in 
many  small  segments.  Better  performance  may  be  achieved  using  fewer  large 
segments.  In  general,  if  both  sending  and  receiving  window  management  algo¬ 
rithms  actively  attempt  to  combine  small  window  allocations  into  larger  win¬ 
dows,  the  tendency  toward  small  segments  can  be  avoided. 

One  suggestion  to  avoid  small  windows  is  for  a  receiving  TCP  to  defer  updating 
a  window  until  an  allocation  is  at  least  X  percent  of  the  maximum  allocation 
possible  for  the  connection  (where  X  might  be  20  to  40).  Thus,  the  TCP  could 
be  send  an  ACK  when  a  segment  arrives  (without  updating  the  winoow  informa¬ 
tion),  and  later  send  another  ACK  with  the  larger  window.  Another  suggestion 
is  for  the  sending  TCP  to  avoid  sending  small  segments  by  waiting  until  the 
window  is  "large"  before  sending  data.  (Note  that  acknowledgements  should  not 
be  delayed  or  unnecessary  retransmissions  will  result.) 
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6.1.3  Duplicate  and  Out-of-order  Data  Detection 

The  network  protocol  layer  may  duplicate  or  change  the  order  of  segments  sub¬ 
mitted  by  TCP  for  transmission.  To  compensate,  a  TCP  entity  uses  sequence 
numbers  to  detect  out-of-order  and  duplicate  segments.  Duplicate  segments  are 
discarded.  Segments  arriving  out  of  order  may,  depending  on  implementation 
choices,  be  either  discarded  or  saved  for  subsequent  processing. 

The  duplicate  detection  and  sequencing  algorithms  rely  on  the  unique  binding 
of  segment  data  to  tequence  space.  The  algorithms  are  based  on  the  assumption 
that  all  2**32  sequence  number  values  are  not  cycled  through  before  the  seg¬ 
ment  data  bound  to  those  sequence  numbers  has  been  delivered  and  acknowledged 
by  the  receiver  and  all  duplicate  copies  of  the  segments  have  "drained"  from 
the  internet.  Without  such  an  assumption,  two  distindt  TCP  segments  could 
conceivably  be  assigned  the  same  or  overlapping  sequence  numbers,  causing  con¬ 
fusion  at  the  receiver  as  to  which  data  is  new  and  which  is  old.  This  topic 
i s  d i scussed  in  [10]  . 

A  sending  TCP  entity  keeps  track  of  the  sequence  number  of  the  next  data  octet 
to  send  in  the  variable  SEN0_NEXT.  In  each  outgoing  segment,  the  entity 
records  the  sequence  number  of  the  first  data  octet  in  the  segment  header 
field,  SEG.SEQ,  and  advances  SEN0_NEXT  by  the  total  amount  of  data  carried  in 
the  segment.  A  receiving  TCP  entity  keeps  track  of  the  sequence  number  of  the 
next  data  octet  expected  in  the  variable  RECV_NEXT.  That  value  and  the  vari¬ 
able  RECV_WNDW  represent  the  receive  window,  or  interval  of  acceptable  data 
octets.  This  interval  is  compared  against  incoming  segment  sequence  numbers 
to  determine  their  "acceptability.'1 

An  incoming  segment  is  defined  to  be  acceptable  if  any  data  it  carries  falls 
within  the  receive  window.  If  the  segment  does  not  carry  data,  the  segment 
sequence  number  must  fall  within  the  receive  window.  When  the  receive  window 
is  zero,  a  segment  is  acceptable  if  its  sequence  number  equal  the  next 
expected  sequence  number,  RECV_NEXT. 

The  processing  of  unacceptable  segments  is  discussed  in  6.1,3. 

The  control  information,  including  valid  acknowledgment,  window  and  urgent 
information,  must  be  used  from  every  acceptable  segment.  However,  the  policy 
for  taking  (i.e.,  adding  to  to  the  receive  queue)  the  data  of  an  acceptable 
segment  can  be  approached  in  two  ways.  The  first  approach  takes  only  in-order 
data.  That  is,  only  data  octets  with  sequence  numbers  starting  at  RECV.NEXT 
and  continuing  through  to  either  the  end  of  the  segment  or  the  end  of  the 
receive  window  (whichever  is  shorter)  are  taken.  The  data  octets  of  accept¬ 
able  segments  with  sequence  numbers  starting  beyond  RECV.NEXT  are  not  taken. 
This  "in-order"  approach  allows  immediate  acknowledgment  and  delivery  to  the 
ULP . 

The  second  approach,  called  in-window  data  acceptance,  takes  any  data  falling 
within  the  receive  window.  If  the  data  is  not  contiguous  with  previously 
received  data,  it  is  saved  for  processing  until  the  intervening  data  arrives. 
Thus,  acknowledgment  and  delivery  will  be  delayed  until  a  contiguous  interval 
of  data  arrives. 
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6.1.4  Positive  Acknowledgement  With  Retransmission 

Another  mechanism  compensating  for  network  protocol  behavior  is  positive  ack¬ 
nowledgement  with  retransmission.  This  mechanism  replaces  data  lost  or  dam¬ 
aged  in  transit  through  the  use  of  sequence  numbers  and  acknowledgements.  The 
basic  strategy  with  PAR  is  for  a  sending  TCP  to  retransmit  a  segment  at  timed 
intervals  until  a  positive  acknowledgement  is  returned.  The  mechanism 
requirements  for  segment  retransmission,  acknowledgement  acceptance,  transmis¬ 
sion  intervals,  and  sequence  variable  manipulation  are  described  below. 

The  PAR  strategy  requires  TCP  to  keep  copies  of  all  segments  in  order  on  a 
"retransmission  queue."  As  each  segment  is  sent,  a  segment  copy  is  placed  on 
the  end  of  the  queue.  The  retransmission  queue  holds  the  data  octets  whose 
sequence  numbers  begin  with  SEND__UNA,  the  oldest  unacknowledged  sequence 
number,  and  ends  with  SEND_NEXT,  the  next  octet  to  be  sent.  When  all  sent 
data  has  been  acknowledged,  SEND_UNA  equals  SEND_NEXT,  and  the  retransmission 
queue  is  empty. 

When  data  is  placed  on  the  retransmission  queue,  a  timer  is  set  for  the  inter¬ 
val  expected  to  elapse  before  its  acknowledgement  returns.  When  a  segment  or 
an  acknowledgement  is  lost,  the  retransmission  timer  will  expire  and  the  TCP 
will  retransmit  the  unacknowledged  data. 

If  the  original  segment  was  lost  or  discarded  due  to  damage,  the  retransmitted 
segment  is  accepted  as  the  original  at  the  receiving  TCP.  If  the  acknowledge¬ 
ment  was  lost,  the  receiving  TCP  discards  the  retransmitted  segment  as  a 
duplicate,  but  resends  its  acknowledgement. 


6. 1.4.1  Acknowledgement  Generat i on  Every  TCP  segment,  excluding  an  initial 
SYN  segment,  must  carry  an  acknowledgement  indicating  current  receive  variable 
information.  Acknowledgements  are  carried  in  the  TCP  segment  header  in  a  four 
octet  field  designating  the  sequence  number  of  the  next  expected  data  octet. 
The  acknowledgement  mechanism  is  cumulative  so  that  an  ACK  of  sequence  number 
X  indicates  that  all  octets  up  to  but  not  including  X  have  been  received. 
Thus,  a  TCP  entity  sets  the  ACK  field  of  each  outgoing  segment  to  the  value  of 
RECV_NEXT,  implicitly  stating  that  it  has  successfully  received  every  data 
octet  up  to  that  sequence  number. 

An  acknowledgement  does  not  guarantee  that  data  has  been  delivered  to  the  ULP, 
but  only  that  the  destination  TCP  has  taken  the  responsibility  to  do  so. 


6. 1.4. 2  ACK  Va 1 i dat i on  Incoming  acknowledgments  are  compared  with  the  send 
variables  to  determine  their  "acceptability."  An  "acceptable  ACK"  is  one  for 
which  the  inequality  holds: 

SENOJJNA  =<  SEG.ACK  -<  $END_NEXT 

In  other  words,  the  acknowledgement  refers  to  data  equal  to  or  beyond  that 
already  acknowledged,  and  yet  does  not  exceed  the  sequence  number  of  data  yet 
to  be  sent.  If  SEG.ACK  <  SEND_UNA,  it  i s  an  old  ACK  and  is  unacceptable.  If 
SEG.ACK  >  $END_NEXT,  it  acknowledges  data  not  yet  sent,  and  so  is 
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unacceptab I e . 

When  an  acceptable  ACK  equals  SEND_UNA,  no  new  data  is  acknowledged  but  new 
window  information  may  be  present.  When  an  acceptable  ACK  is  greater  than 
SEN0_UNA,  it  becomes  the  new  value  for  SEND_UNA. 

6. 1.1*. 3  Retransm i ss i on  Queue  Remova 1 s  Acknowledgements  are  not  only  used  to 
update  SEND_WNDW  and  SEN0_UNA,  they  are  also  processed  with  respect  to  the 
retransmission  queue.  When  an  ACK  arrives  fully  acknowledging  a  segment  on 
the  retransmission  queue,  the  segment  copy  is  removed  from  the  queue.  An  ACK 
is  said  to  fully  acknowledge  a  segment  copy  on  the  retransmission  queue  if  the 
sum  of  the  segment  copy's  sequence  number  and  length  is  less  than  or  equal  to 
the  acknowledgement  number  of  the  incoming  segment. 


6. 1.1*. A  Retransm i ss i on  Strateq i es  A  TCP  implementation  may  employ  one  of 
several  retransmission  strategies. 

a.  First-only  retransmission  -  The  TCP  entity  maintains  one  retransmission 
timer  for  the  entire  queue.  When  the  retransmiss ion  timer  expires,  it 
sends  the  segment  (or  a  segment's  worth  of  data)  at  the  front  of  the 
retransmission  queue  and  resets  the  timer. 

b.  Batch  retransmission  -  The  TCP  entity  maintains  one  retransmission  timer 
for  the  entire  queue.  When  the  retransmission  timer  expires,  it  sends 
all  the  segments  on  the  retransmission  queue  and  resets  the  timer. 

c.  Individual  retransmission  -  The  TCP  entity  maintains  one  timer  for  each 
segment  on  the  retransmission  queue.  As  the  timers  expire,  the  segments 
are  retransmitted  individually  and  their  timers  reset. 

A  brief  discussion  of  retransm i ss i on  strategy  trade-offs  and  their  relation¬ 
ship  to  the  acceptance  policy  appears  in  Appendix  A. 

6. 1.1*. 5  Retransm i ss i on  T i meouts  The  value  of  the  retransmission  timer  can 
have  a  large  effect  on  the  performance  of  both  the  connection  and  the  network. 
A  timeout  interval  that  is  too  short  results  in  unnecessary  retransmissions, 
wasting  both  TCP  processing  time  and  network  resources,  while  one  that  is  too 
long  results  in  poor  throughput  and  poor  response  time  for  the  UIP. 

Ideally,  the  retransmission  interval  should  equal  exactly  the  time  required 
for  a  segment  to  traverse  the  network  to  its  destination,  be  processed,  and 
its  ACK  to  traverse  the  network  back  to  the  source.  This  sum  is  called  the 
Round  Trip  Time  (RTT) .  Realistically,  however,  this  value  is  rarely  known  or 
constant.  Instead,  an  approximation  of  this  sum  can  be  dynamically  computed 
during  the  lifetime  of  a  connection. 


I 
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6.1.5  Checksum 

The  checksum  mechanism  supports  error-free  data  transfer  service  by  enabling 
detection  of  segments  damaged  in  transit.  A  checksum  value  is  computed  for 
each  outbound  segment  and  placed  in  the  header's  checksum  field.  Similarly, 
the  checksum  of  each  incoming  segment  is  computed  and  compared  against  the 
value  of  the  header's  checksum  field.  If  the  values  do  not  match,  the  incom¬ 
ing  segment  is  discarded  without  being  acknowledged.  Hence,  a  damaged  segment 
appears  the  same  as  a  lost  segment  and  is  compensated  for  by  the  PAR  mechan- 
i  sm. 


TCP  uses  a  simple  one's  complement  algorithm  which  covers  the  segment  header, 
the  segment  data,  and  a  "pseudo  header."  The  pseudo  header  is  made  up  of  the 
source  address,  the  destination  address,  TCP's  protocol  identifier  [5],  and 
the  length  of  the  TCP  segment  (excluding  the  pseudo  header).  By  including  the 
extra  pseudo  header  information  in  the  checksum,  TCP  protects  itself  from  mis¬ 
delivery  by  the  network  protocol. 

The  checksum  algorithm  is  the  16  bit  one's  complement  of  the  one's  complement 
sum  of  all  16  bit  words  in  the  pseudo  header,  segment  header,  and  the  segment 
text.  If  a  segment  contains  an  odd  number  of  octets,  the  last  octet  is  padded 
on  the  right  with  zeros  to  form  a  l6-bit  word  for  checksum  purposes.  While 
computing  the  checksum,  the  checksum  field  itself  is  replaced  with'zeros. 


6.1.6  Push  * 

The  data  that  flows  on  a  connection  is  conceptually  a  stream  of  octets.  A 
sending  TCP  is  allowed  to  collect  data  from  the  sending  ULP  and  to  segment  and 
send  the  data  at  its  own  convenience.  The  sending  ULP  has  no  way  of  knowing 
if  the  data  has  been  sent  or  is  retained  by  the  local  TCP  or  remote  TCP  while 
waiting  for  a  more  suitable  segment  or  delivery  size.  This  mechanism  enables 
a  ULP  to  push  data  through  both  the  local  and  remote  TCP  entities. 

When  "push"  flag  is  set  in  a  SEND  request,  the  sending  TCP  segments  and  sends 
all  internally  stored  data  within  flow  control  limits.  Upon  receipt  of  a 
pushed  segment,  the  receiving  TCP  must  promptly  deliver  the  pushed  data  to  the 
receiving  ULP. 

Successive  pushes  may  not  be  preserved  because  two  or  more  units  of  pushed 
data  may  be  joined  into  a  single  pushed  unit  by  either  the  sending  or  receiv¬ 
ing  TCP.  Pushes  are  not  visible  to  the  receiving  ULP  and  are  not  intended  to 
serve  as  a  record  boundary  marker. 


6.1.7  Urgent 

TCP  provides  a  means  to  communicate  to  a  receiving  ULP  that  some  point  in  the 
upcoming  data  stream  has  been  marked  urgent  by  the  sending  ULP.  Also,  the 
receiving  TCP  can  indicate  when  all  the  currently  know  urgent  data  has  been 
delivered  to  the  receiving  ULP.  The  objective  of  the  TCP  urgent  mechanism  is 
to  enable  the  sending  ULP  to  stimulate  the  receiving  ULP  to  accept  some  urgent 
data.  TCP  does  not  define  what  the  ULP  is  required  to  do  with  the  urgent 
state  information,  but  the  general  notion  is  that  the  receiving  ULP  will  take 
action  to  process  the  intervening  data  quickly. 
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The  urgent  mechanism  permits  a  point  in  the  data  stream  to  be  designated  as 
the  end  of  urgent  information.  Whenever  this  point  is  in  advance  of  the  vari¬ 
able  RECV_NEXT  at  the  receiving  TCP,  that  TCP  must  tell  the  ULP  to  go  into 
"urgent  mode;"  when  the  receive  sequence  number  catches  up  to  the  urgent 
pointer,  the  TCP  must  tell  the  ULP  to  go  into  "normal  mode."  If  the  point  is 
updated  while  the  ULP  is  in  urgent  mode,  the  update  will  be  invisible  to  the 
ULP.  Note  that  urgent  data  cannot  be  delivered  together  with  any  non-urgent 
data  that  may  follow. 

The  mechanism  employs  an  urgent  field  which  is  carried  in  all  segments 
transmitted.  The  URG  control  flag  indicates  that  the  urgent  field  is  meaning¬ 
ful.  The  urgent  field  must  be  added  to  the  segment  sequence  number  to  yield 
the  sequence  number  of  the  last  octet  of  urgent  data.  The  absence  of  this 
flag  indicates  that  there  is  no  urgent  data  outstanding. 

To  send  an  urgent  indication  the  ULP  must  also  send  at  least  one  data  octet. 
If  the  sending  ULP  also  indicates  a  push,  timely  delivery  of  the  urgent  infor¬ 
mation  to  the  destination  process  is  enhanced.  When  an  urgent  indication 
appears  in  a  Send  service  request  but  the  send  window  does  not  allow  data  to 
be  sent  immediately,  the  TCP  should  send  an  empty  ACK  segment  with  the  new 
urgent  information. 


8.1.8  ULP  Timeout 

The  timeout  allows  a  ULP  to  set  up  a  timeout  for  all  data  submitted  to  the  TCP 
entity.  If  some  data  is  not  successfully  delivered  to  the  destination  within 
the  timeout  period,  the  TCP  entity  will  terminate  the  connection. 

The  timeout  appears  as  an  optional  parameter  in  the  open  requests  and  the  send 
request.  Upon  receiving  either  an  active  open  request,  or  a  SYN  segment  after 
a  passive  request,  the  TCP  entity  must  maintain  a  timer  set  for  the  interval 
specified  by  the  ULP.  As  acknowledgements  arrive  from  the  remote  TCP,  the 
timer  is  cancelled  and  set  again  for  the  timeout  interval.  As  a  parameter  of 
the  SEND  request,  the  timeout  can  change  during  connection  lifetime.  If  the 
timeout  is  reduced  below  the  age  of  data  waiting  to  be  acknowledged,  the  con¬ 
nection  is  terminated  and  the  ULP  is  informed. 


6.1.9  Security  and  Precedence 

TCP  makes  use  of  the  Internet  Protocol  (IP)  [8]  options  to  provide  security 
and  precedence  on  a  per  connection  basis.  The  security  and  precedence  parame¬ 
ters  used  in  TCP  are  those  defined  in  IP.  Throughout  this  TCP  specification 
the  term  "security  information"  indicates  the  security  parameters  used  in  IP, 
including  security  level,  compartment,  user  group,  and  handling  restrictions. 

In  order  for  a  TCP  connection  to  be  established,  the  modules  at  each  end  of 
the  connection  must  agree  on  the  security  information  and  precedence  to  be 
associated  with  the  connection.  When  system  reauirements  allow  a  choice  of 
precedence  levels  and  security  information,  such  as  in  a  multilevel  secure 
environment,  these  parameters  may  be  negotiated;  for  other  systems  that 
operate  at  a  single  security  level  or  in  an  unclassified  environment, 
predetermi ned  values  must  be  used. 
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The  precedence  level  of  the  connection  is  negotiated  through  the  exchange  of 
lower  bounds  by  each  end  during  connection  opening.  The  higher  of  the  two 
values  is  assigned  to  the  connection.  If  it  is  impossible  for  the  end  with 
the  lower  precedence  to  raise  its  level  to  the  higher,  or  to  get  the  security 
information  to  match  exactly,  the  connection  must  be  rejected.  The  inability 
to  match  security  information  or  precedence  levels  is  indicated  by  the  receipt 
of  segments  after  the  connection  opening  with  the  non-matching  information. 
The  connection  is  then  rejected  by  sending  a  reset.  In  addition  to  sending  a 
reset,  the  connection  attempt  with  mismatched  security  information  may  be 
reported  or  recorded  in  accordance  with  local  standard  operating  procedures. 

After  the  connection  is  established,  the  TCP  modules  must  mark  outgoing  seg¬ 
ments  with  the  agreed  security  information  and  precedence  level.  Any  incoming 
segment  with  security  information  or  precedence  level  not  exactly  matching 
that  of  the  connection  causes  the  termination  of  the  connection.  A  reset  is 
sent  to  the  remote  TCP  and  the  local  !JLP  is  informed  of  the  error. 

6.1.10  Multiplexing 

TCP  provides  a  set  of  addresses,  called  port  identifiers,  to  allow  for  many 
ULPs  within  a  single  host  to  use  TCP  communication  facilities  simultaneously 
and  to  identify  the  separate  data  streams  that  a  ULP  may  request.  Port  iden¬ 
tifiers  are  selected  independently  by  each  TCP  entity.  To  provide  unique 
addresses,  TCP  concatenates  an  internet  address  identifying  its  internet  loca¬ 
tion  to  a  port  identifier  creating  a  "socket."  Thus,  sockets  are  unique 
throughout  the  internetwork  and  a  pair  of  sockets  can  uniquely  identify  each 
TCP  connection.  A  socket  may  participate  in  many  connections  to  different 
foreign  sockets. 

TCPs  are  free  to  associate  ports  with  processes  however  they  choose.  However, 
several  basic  concepts  are  necessary  in  any  implementation.  There  are  "well- 
known"  sockets  which  a  TCP  entity  associates  only  with  the  "appropriate"  ULP 
by  some  means.  Well-known  sockets  are  a  convenient  mechanism  for  a  priori 
associating  a  socket  address  with  a  standard  service.  For  instance,  the 
"Telnet-Server"  process  is  permanently  assigned  to  a  particular  socket,  and 
other  sockets  are  reserved  for  File  Transfer,  Remote  Job  Entry,  Text  Genera¬ 
tor,  Echoer,  and  Sink  processes  (the  last  three  being  for  test  purposes).  A 
socket  address  might  be  reserved  for  access  to  a  "Look-Up"  service  which  would 
return  the  specific  socket  at  which  a  newly  created  service  would  be  provided. 
The  concept  of  a  well-known  socket  is  part  of  the  TCP  specification,  but  the 
assignment  of  sockets  to  services  is  outside  this  specification  [5]. 


6.1.11  Connection  Opening  Mechanisms 

Several  mechanisms  are  used  to  establish  connections  between  two  TCP  entities. 
These  mechanisms,  including  open  requests,  sequence  number  synchronization, 
and  initial  sequence  number  generation,  are  discussed  below. 


6.1.11.1  Connect i on  Open  Requests  TCP  provides  a  ULP  with  two  ways  of  open¬ 
ing  a  connection,  called  passive  open  requests  and  active  open  requests.  The 
open  requests  have  certain  parameters  including  the  local  socket  and  foreign 
socket  naming  the  connection. 
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With  a  passive  open  request,  the  TCP  entity  assigns  a  state  vector  for  the 
connection  variables,  returns  a  local  connection  name,  and  becomes  "receptive" 
to  connections  with  other  ULPs.  The  foreign  socket  parameter  in  a  passive 
open  request  may  be  either  fully  specified  or  unspecified.  That  is,  when  the 
foreign  socket  parameter  is  set  to  a  specific  socket  value,  only  the  ULP  with 
that  socket  identifier  can  be  connected.  If  the  foreign  socket  is  unspecified 
(denoted  by  all  zeros)  any  ULP  can  be  connected.  Such  unspecified  foreign 
sockets  are  allowed  only  on  passive  open  requests.  A  service  ULP  that  wished 
to  provide  services  for  unknown  other  ULPs  would  issue  an  unspecifed  passive 
open  request,  supplying  its  own  well-known  socket  for  the  local  socket. 

With  an  active  open  request,  the  TCP  entity  not  only  assigns  a  state  vector 
and  a  local  connection  name,  but  also  actively  initiates  the  connection  by 
sending  a  SYN  segment.  A  connection  is  initiated  by  the  rendezvous  of  an 
arriving  segment  containing  a  SYN  and  a  waiting  state  vector. 

The  matching  of  local  and  foreign  sockets  determines  when  a  connection  has 
been  initiated.  There  are  two  principal  cases  for  matching  the  sockets  in  the 
local  open  requests  to  the  foreign  sockets  in  arriving  SYN  segments.  In  the 
first  case,  the  local  open  has  fully  specified  the  foreign  socket  so  the  match 
must  be  exact.  In  the  second  case,  the  local  passive  open  has  left  the 
foreign  socket  unspecified  so  any  foreign  socket  is  acceptable  as  long  as  the 
local  sockets  match.  Other  possibilities,  left  up  to  the  implementor,  include 
partially  restricted  matches. 

ft 

If  there  are  several  pending  open  requests  with  the  same  local  socket,  a 
foreign  active  open  will  be  matched  to  to  a  fully  specified  open,  if  one 
exists,  before  selecting  an  unspecified  passive  open. 


6.1.11.2  Three-Way  Handshake  The  "three-way  handshake"  is  the  mechanism  used 
to  establish  a  connection.  This  procedure  normally  is  initiated  by  one  TCP 
and  responded  to  by  another  TCP.  The  procedure  also  works  if  two  TCPs  simul¬ 
taneously  initiate  the  procedure.  When  two  ULPs  wish  to  to  communicate,  they 
issue  open  requests  as  described  above,  instructing  their  TCPs  to  initialize 
and  synchronize  the  mechanism  information  on  each  side.  However,  the  poten¬ 
tially  unreliable  network  layer  can  complicate  the  process  of  synchronization. 
Delayed  or  duplicate  segments  from  previous  connection  attempts  might  be  mis¬ 
taken  for  new  ones.  A  handshake  procedure  with  clock  based  sequence  numbers 
is  used  in  connection  opening  to  reduce  the  possibility  of  such  false  connec¬ 
tions. 

In  the  simplest  handshake  between  an  active  open  request  and  a  passive  open 
request,  the  TCP  pair  synchronizes  sequence  numbers  by  exchanging  three  seg¬ 
ments.  The  actively  opened  TCP  entity  emits  a  segment  marked  with  a  synchron¬ 
ize  control  flag,  called  a  "SYN"  segment,  which  is  matched  at  the  receiving 
TCP  entity  to  the  passive  open  request.  The  receiving  TCP  entity  emits  its 
own  SYN  also  carrying  an  acknowledgement  of  the  first  SYN.  That  segment  is 
responded  to  with  an  acknowledgement.  Thus,  a  three  segment  exchange  estab¬ 
lishes  the  connection. 


When  simultaneous  active  open  requests  initiate  the  connection  each  TCP 
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receives  a  SYN  segment  which  carries  no  acknowledgement  after  it  has  sent  a 
SYN.  Each  respond  with  an  acknowledging  segment  and  a  connection  is  esta¬ 
blished  in  four  exchanges.  Of  course,  the  arrival  of  an  old  duplicate  SYN 
segment  can  potentially  make  it  appear,  to  the  recipient,  that  a  simultaneous 
connection  initiation  is  in  progress.  Proper  use  of  "reset"  segments  will 
disambiguate  these  cases. 

Several  examples  of  connection  initiation  follow.  Although  these  examples  do 
not  show  connection  synchronization  using  dnta-carry i ng  segments,  this  is  per¬ 
fectly  legitimate,  so  long  as  the  receiving  TCP  doesn't  deliver  the  data  to 
the  ULP  until  it  is  clear  the  data  is  valid  (i.e.,  the  data  must  be  buffered 
at  the  receiver  until  the  connection  reaches  the  ESTABLISHED  state).  The 
three-way  handshake  reduces  the  possibility  of  false  connections.  It  is  the 
implementation  of  a  trade-off  between  memory  and  messages  to  provide  informa¬ 
tion  for  this  checking. 

The  simplest  three-way  handshake  is  shown  in  the  scenario.  Section  1.1.  Other 
examples  are  shown  below.  The  figures  should  be  interpreted  in  the  following 
way.  Each  line  is  numbered  for  reference  purposes.  Right  arrows  (-->)  indi¬ 
cate  departure  of  a  TCP  segment  from  TCP  A  to  TCP  B,  or  arrival  of  a  segment 
at  B  from  A.  Left  arrows  (< — )  indicate  the  reverse.  Ellipsis  (...)  indi¬ 
cates  a  segment  which  is  still  in  the  network  (delayed).  An  "XXX"  indicates  a 
segment  which  is  lost  or  rejected.  Comments  appear  in  parentheses.  TCP 
states  represent  the  state  AFTER  the  departure  or  arrival  of  the  segment 
(whose  contents  are  shown  in  the  center  of  each  line).  Segment  contents  are 
shown  in  abbreviated  form,  with  sequence  number,  control  flags,  and  ACK  field. 
Other  fields  such  as  window,  addresses,  lengths,  and  text  have  been  left  out 
in  the  interest  of  clarity. 

Simultaneous  Connection  Initiation  Simultaneous  initiation  is  only  slightly 
more  complex  than  a  three-way  handshake.  Each  TCP  cycles  from  CLOSED  to  SYN- 
SENT  to  SYN-RECE I VED  to  ESTABLISHED. 


TCP  A 

TCP 

B 

1 . 

CLOSED 

CLOSED 

2. 

SYN-SENT 

<SEQ«100><CTL=SYN> 

3. 

SYN-RECE 

IVED 

<-- 

<SEQ-300><CTL-SYN> 

< - 

SYN-SENT 

k. 

<SEQ*100><CTL-SYN> 

- > 

SYN-RECE 1 

IVED 

5. 

SYN-RECE 

IVED 

--> 

<SEQ-100><ACK-301><CTL-SYN,ACK> 

6. 

ESTABLISHED 

< - 

<SEQ-300><ACK-101><CTL-SYN,ACK> 

<  — 

SYN-RECE 1 

IVED 

7. 

•  •  • 

<SEQ-101XACK-301XCTL«ACK> 

-•> 

ESTABLISHED 

Simultaneous  Connection  Synchronization 


;j 
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The  principal  reason  for  the  three-way  handshake  is  to  prevent  old  duplicate 
connection  initiations  from  causing  confusion.  To  deal  with  this,  a  special 
control  message,  reset,  is  used.  If  the  receiving  TCP  is  in  a  nonsynchron- 
ized  state  (i.e.,  SYN-SENT,  SYN-RECE 1 VED) ,  it  returns  to  LISTEN  on  receiving 
an  acceptable  reset.  If  the  TCP  is  in  one  of  the  synchronized  states  (ESTA¬ 
BLISHED,  FIN-WAIT-1,  FIN-WAIT-2,  CLOSE-WAIT,  CLOSING,  LAST-ACK,  TIME-WAIT),  it 
aborts  the  connection  and  informs  its  ULP.  This  case  is  discussed  under 
"half-open"  connections  below. 

0 1 d  Pup  I i cate  SYN  Detect i on  As  a  simple  example  of  recovery  from  old  dupli¬ 
cates,  consider  the  following  figure.  At  line  3,  an  old  duplicate  SYN  arrives 
at  TCP  B.  TCP  B  cannot  tell  that  this  is  an  old  duplicate,  so  it  responds 
normally  (line  4).  TCP  A  detects  that  the  ACK  field  is  incorrect  and  returns 
a  RST  (reset)  with  its  SEQ  field  selected  to  make  the  segment  believable.  TCP 
B,  on  receiving  the  RST,  returns  to  the  LISTEN  state.  When  the  original  SYN 
finally  arrives  at  line  6,  the  synchronization  proceeds  normally.  If  the  SYN 
at  line  6  had  arrived  before  the  RST,  a  more  complex  exchange  might  have 
occurred  with  RSTs  sent  in  both  directions. 


TCP  A 

TCP  B 

I . 

CLOSED 

LISTEN 

2. 

SYN-SENT 

--> 

<SEQ-100><CTL*SYN> 

3. 

(dupl  i  cate) 

<SEQ=90><CTL=SYN> 

— >  SYN-RECE 1 VED 

4. 

SYN-SENT 

<-- 

<SEQ=300><ACK=9 1 ><CTL=SYN , ACK> 

<--  SYN-RECE 1 VED 

5- 

SYN-SENT 

--> 

<SEQ=91><CTL=RST> 

— >  LISTEN 

6. 

*  •  • 

<SEQ=100><CTL“SYN> 

-->  SYN-RECE 1 VED 

7. 

SYN-SENT 

<-- 

<SEQ»400><ACK*101><CTL=SYN, ack> 

<--  SYN-RECE 1 VED 

8. 

ESTABLISHED 

--> 

<SEQ= 1 0 1 ><ACK*40 1 ><CTL=ACK> 

-->  ESTABLISHED 

Recovery  from  Old  Duplicate  SYN 


Half-Open  Connections  and  Other  Anoma 1 i es  An  established  connection  is  said 
to  be  "half-open"  if  one  of  the  TCPs  has  closed  or  aborted  the  connection  at 
its  end  without  the  knowledge  of  the  other,  or  if  the  two  ends  of  the  connec¬ 
tion  have  become  desynchron i zed  owing  to  a  crash  that  resulted  in  loss  of 
memory.  Such  connections  will  automatically  become  reset  if  an  attempt  is 
made  to  send  data  in  either  direction.  However,  half-open  connections  are 
expected  to  be  unusual,  and  the  recovery  procedure  is  somewhat  involved. 
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If  at  site  A  the  connection  no  longer  exists,  then  an  attempt  by  the  ULP  at 
site  B  to  send  any  data  on  it  will  result  in  the  site  B  TCP  receiving  a  reset 
control  message.  Such  a  message  indicates  to  the  site  B  TCP  that  something  is 
wrong,  and  it  is  expected  to  abort  the  connection. 

Assume  that  two  ULPs  A  and  B  are  communicating  with  one  another  when  a  crash 
occurs  causing  loss  of  memory  to  A's  TCP.  Depending  on  the  operating  system 
supporting  ULP  A's  TCP,  it  is  likely  that  some  error  recovery  mechanism 
exists.  When  the  TCP  is  up  again,  ULP  A  is  likely  to  start  again  from  the 
beginning  or  from  a  recovery  point.  As  a  result,  ULP  A  will  probably  try  to 
OPEN  the  connection  again  or  try  to  SEND  on  the  connection  it  believes  open. 
In  the  latter  case,  it  receives  the  error  message  "connection  not  open"  from 
the  local  (ULP  A's)  TCP.  In  an  attempt  to  establish  the  connection,  ULP  A's 
TCP  will  send  a  segment  containing  SYN.  This  scenario  leads  to  the  example 
shown  in  figure  10.  After  TCP  A  crashes,  the  ULP  attempts  to  open  the  connec¬ 
tion  again.  TCP  B,  in  the  meantime,  thinks  the  connection  is  open. 


TCP  A 

1 .  (CRASH) 

2.  CLOSED 

3.  SYN-SENT  — >  <SEQ»i*00><CTL-SYN> 

A.  (! ! I !)  <--  <SEQ-300><ACK*100><CTL=ACK> 

5.  SYN-SENT  — >  <SEQ«100><CTL=RST> 

6.  SYN-SENT 

7.  SYN-SENT  -->  <SEQ*400><CTL*SYN> 

Half-Open  Connection  Discovery 


TCP  B 

(send  300, receive  100) 
ESTABLISHED 
”>  (??) 

<—  ESTABLISHED 
-->  (Abort! ! ! !) 
CLOSED 


When  the  SYN  arrives  at  line  3>  TCP  B,  being  in  a  synchronized  state,  sees  the 
incoming  segment  outside  the  window  and  responds  with  an  acknowledgement  indi¬ 
cating  what  sequence  it  next  expects  to  hear  (ACK  100).  TCP  A  sees  that  this 
segment  does  not  acknowledge  anything  it  sent  and,  being  unsynchronized,  sends 
a  reset  (RST)  because  it  has  detected  a  half-open  connection.  TCP  B  aborts  at 
line  5-  TCP  A  wi 1 1  continue  to  try  to  establish  the  connection;  the  problem 
is  now  reduced  to  the  basic  3-way  handshake. 

An  interesting  alternative  case  occurs  when  TCP  A  crashes  and  TCP  B  tries  to 
send  data  on  what  i:  thinks  is  a  synchronized  connection.  This  is  illustrated 
in  the  next  figure.  In  this  case,  the  data  arriving  at  TCP  A  from  TCP  B  (line 
2)  is  unacceptable  because  no  such  connection  exists,  so  TCP  A  sends  a  RST. 
The  RST  is  acceptable  so  TCP  B  processes  it  and  aborts  the  connection. 
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TCP  A  TCP  B 

1.  (CRASH)  (send  300, receive  100) 

2.  (??)  <--  <SEQ=300><ACK=100><DATA=10><CTl=ACK>  <--  ESTABLISHED 

3.  — >  <SEQ=100><CTL=RST>  — >  (ABORT!!!!) 

Active  Side  Causes  Half-Open  Connection  Discovery 


In  the  following  figure,  TCPs  A  and  B  with  passive  opens  are  waiting  for  SYNs. 
An  old  duplicate  arriving  at  TCP  B  (line  2)  stirs  B  into  action.  A  SYN-ACK  is 
returned  (line  3)  and  causes  TCP  A  to  generate  a  RST  (the  ACK  in  line  3  is  not 
acceptable).  TCP  B  accepts  the  reset  and  returns  to  its  passive  LISTEN  state. 


TCP  A 

TCP  B 

1 . 

LISTEN 

LISTEN 

2. 

.  .  . 

<SEQ=Z><CTL*SYN> 

— >  SYN-RECE 1 VED 

3- 

(??)  <~ 

<SEQ»X><ACK«Z+1><CTL*SYN,ACK> 

<—  SYN-RECE  1  VED 

A. 

--> 

<SEQ=Z+1><CTL*RST> 

-->  (return  to  LISTEN!!) 

5. 

LISTEN 

LISTEN 

Old  0"plicate  SYN  Initiates  a  Reset  on  two  Passive  Sockets 


A  variety  of  other  cases  is  possible,  all  of  which  are  accounted  for  by  the 
reset  generation  and  processing. 

6.1.11.3  Initial  Sequence  Number  Selection  TCP  imposes  no  restrictions  on  a 
particular  connection  being  used  over  and  over  again.  A  connection  is  only 
named  by  a  pair  of  sockets.  New  instances  of  a  connection  will  be  referred  to 
as  incarnations  of  the  connection.  The  problem  that  arises  is  how  to  identify 
duplicate  segments  from  previous  incarnations  of  the  connection.  This  problem 
becomes  apparent  if  the  connection  is  being  opened  and  closed  in  quick  succes¬ 
sion,  or  if  the  connection  breaks  with  loss  of  memory  and  is  then  reesta- 
bl i shed. 

To  avoid  confusion,  segments  from  one  incarnation  of  a  connection  must  not  be 
used  while  the  same  sequence  numbers  may  still  be  present  in  the  network  from 
an  earlier  incarnation.  This  must  be  assured,  even  if  a  TCP  crashes  and  loses 
all  knowledge  of  the  sequence  numbers  it  has  been  using.  Thus,  a  clock-based 
initial  sequence  number  generation  procedure  has  been  defined. 
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6.1.11.4  I SN  Generator  When  new  connections  are  created,  an  initial  sequence 
number  (ISN)  generator  is  employed  which  selects  a  new  32-bit  ISN.  The  gen¬ 
erator  is  bound  to  a  (possibly  fictitious)  32-bit  clock  whose  low  order  bit  is 
incremented  roughly  every  It  microseconds.  Thus,  the  ISN  cycles  approximately 
every  hours.  Assuming  segments  will  stay  in  the  network  no  more  than  the 
Maximum  Segment  Lifetime  (MSL)  and  that  the  MSL  is  less  than  L.55  hours,  ISNs 
will  be  unique.  The  advantages  of  this  technique  are  discussed  in  [10]. 

6.1.12  Connection  Closing  Synchronization 

Connection  closing  is  handled  similarly  to  connection  establishment.  The  fol¬ 
lowing  mechanism,  including  close  request  and  fin  exchange,  support  the  reli¬ 
able  data  transport  and  graceful  connection  closing  services. 

6.1.12.1  Close  Requests  A  close  request  indicates  that  the  local  ULP  has 
completed  its  data  transfer  over  the  connection.  A  ULP  may  close  a  connection 
at  any  time  on  its  own  initiative.  Closing  connections  is  intended  to  be  a 
graceful  operation  in  the  sense  that  outstanding  send  requests  will  be 
transmitted  (and  retransmitted),  as  flow  control  permits,  until  all  have  been 
serviced.  Thus,  it  should  be  acceptable  to  make  several  send  requests,  fol¬ 
lowed  by  a  close  request,  and  expect  all  the  data  to  be  sent  to  the  destina¬ 
tion  ULP. 

It  should  also  be  clear  that  ULPs  should  continue  to  accept  data  on  closing 
connections,  since  the  other  ULP  may  be  trying  to  transmit  the  last  of  its 
data.  Thus*,  a  close  request  means  "I  have  no  more  to  send"  but  does  not  mean 
"I  will  not  receive  ar  more."  It  may  happen  (if  the  upper  level  protocol  is 
not  well  thought  out'  ,at  the  closing  side  is  unable  to  get  rid  of  all  its 
data  before  timing  out.  In  this  event,  a  close  turns  into  abort  request,  and 
the  closing  TCP  gives  up. 

Because  closing  a  connection  requires  communication  with  the  foreign  TCP,  con¬ 
nections  may  remain  in  the  closing  state  for  a  short  time.  Attempts  to  reopen 
the  connection  before  the  TCP  replies  to  the  close  request  will  result  in 
error  responses. 

A  close  service  request  also  implies  the  push  function. 


6.1.12.2  F I N  Exchange  Examples  The  fin  control  flag  in  the  segment  header  is 
exchanged  with  the  same  synchronization  mechanism,  the  three-way  handshake, 
used  for  connection  opening.  From  the  TCP  entity  perspective,  there  are 


essentially  three  cases  for  FIN  exchange.  One,  the  loca'  ULP  initiates  con¬ 
nection  closing  with  a  CLOSE  service  request.  Two,  the  remote  TCP  entity 
sends  a  FIN  segment  indicating  that  the  remote  ULP  has  issued  a  close  request. 
Three,  both  ULPs  simultaneously  issue  close  requests. 

Case  Loca 1  ULP  I n i t i ates  Connect i on  C 1 ose  In  this  case,  a  FIN  segment  can 
be  constructed  and  placed  on  the  outgoing  segment  queue.  No  further  send 
requests  from  the  ULP  will  be  accepted  by  the  TCP,  and  it  enters  the  FIN- 
WAIT-1  state.  All  segments  preceding  and  including  FIN  will  be  retransmitted 
until  acknowledged.  When  the  other  TCP  has  both  acknowledged  the  FIN  and  sent 
a  FIN  of  its  own,  the  first  TCP  can  ACK  this  FIN.  Note  that  a  TCP  receiving  a 
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FIN  will  ACK  Put  not  send  its  own  FIN  until  its  ULP  has  closed  the  connection 
also. 


TCP  A 

TCP  B 

1 . 

ESTABLISHED 

ESTABLISHED 

2. 

(Close) 

F IN-WAIT- 1 

— >  <SEQ-100><ACK=300><CTL=F IN,ACK> 

-->  CLOSE-WAIT 

3- 

FIN-WAIT-2 

<--  <SEQ=300><ACK* 1 0 1><CTL=ACK> 

<--  CLOSE-WAIT 

4. 

TIKE -WAIT 

<--  <SEQ=300><ACK*101><CTL=F IN,ACK> 

(Close) 

<—  LAST-ACK 

5. 

T 1 ME-WA 1 T 

-->  <SEQ= 1 0 1 ><ACK*30 1 ><CTL=ACK> 

— >  CLOSED 

6. 

(2  MSL) 
CLOSED 

Normal  Close  Sequence 


Case  2:  TCP  Receives  F I N  from  Remote  TCP  If  an  unsolicited  FIN  arrives  from 
the  network,  the  receiving  TCP  can  ACK  it  and  tell  the  ULP  that  the  connection 
is  closing.  The  ULP  will  respond  with  a  close  request,  upon  which  the  TCP  can 
send  a  FIN  to  the  other  TCP  after  sending  any  remaining  data.  The  TCP  then 
waits  until  its  own  FIN  is  acknowledged  whereupon  it  deletes  the  connection. 
If  an  ACK  is  not  forthcoming,  after  the  ULP  timeout  the  connection  is  aborted 
and  the  ULP  is  informed. 

Case  ULPs  C 1 ose  S i mu  1 taneous 1 y  Simultaneous  close  requests  by  both  ULPs  at 
each  end  of  a  connection  cause  FIN  segments  to  be  exchanged.  When  all  seg¬ 
ments  preceding  the  FINs  have  been  processed  and  acknowledged,  each  TCP  can 
ACK  the  FIN  it  has  received.  Both  will,  upon  nceiving  these  ACKs  delete  the 
connection. 
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TCP  A  TCP  B 

1.  ESTABLISHED  ESTABLISHED 

2.  (ULP  A  issues  CLOSE)  (ULP  B  issues  CLOSE) 


F IN-WAIT- 1 

- > 

<SEQ“100><ACK=300><CTL“F IN, ACK> 

...  FIN-WAIT-1 

<-- 

<SEQ-300><ACK=100XCTL-F  IN,ACK> 

< — 

•  .  . 

<SEQ=100><ACK**300><CTL»F IN,ACK> 

— > 

3. 

CLOSING 

- > 

<SEQ= 1 0 1 ><ACK=30 1 ><CTL*ACK> 

...  CLOSING 

<-- 

<S£Q=30 1 ><ACK= 1 0 1 ><CTL=ACK> 

<-- 

•  .  . 

<SEQ= 10 1 ><ACK*30 1 ><CTL=ACK> 

--> 

TIME-WAIT 

TIME-WAIT 

(2  MSL) 

(2  MSL) 

CLOSED 

Simultaneous  Close  Sequence 

CLOSED 

6.1.12.3  Qu i et  Time  Concept  While  the  clock-based  I SN  generation  prevents 
overlap  of  sequence  number  use  under  normal  conditions,  special  measures  must 
be  taken  in  situations  where  a  host  crashes  (or  restarts),  resulting  in  a 
TCP's  loss  of  knowledge  concerning  the  sequence  numbers  in  use  on  active  con¬ 
nections,  and  the  current  ISN  value.  After  crash  recovery,  a  TCP  may  create 
segments  containing  the  same  or  overlapping  sequence  numbers  as  those  in  pre¬ 
crash  connection  incarnations,  causing  confusion  and  misdelivery  at  the 
receiver.  Even  hosts  managing  to  remember  the  time  of  day  used  as  a  basis  for 
ISN  selection  are  not  immune  to  this  problem,  as  the  following  example  illus¬ 
trates: 

Suppose,  for  example,  that  a  connection  is  opened  starting  with  sequence 
number  S.  Suppose  that  this  connection  is  not  heavily  used  and  that 
eventually  the  initial  sequence  number  function  (ISN(t))  takes  on  a  value 
equal  to  the  sequence  number,  say  SI,  of  the  last  segment  sent  by  this 
TCP  on  a  particular  connection.  Now  suppose,  at  this  instant,  the  host 
crashes,  recovers,  and  establishes  a  new  incarnation  of  the  connection. 
The  initial  sequence  number  chosen  is  SI  ■  I SN  (t)  --  last  used  sequence 
number  on  the  old  incarnation  of  the  connection!!  If  the  recover  occurs 
quickly  enough,  any  old  duplicates  in  the  network  bearing  sequence 
numbers  in  the  neighborhood  of  SI  may  arrive  and  be  accepted  as  new  pack¬ 
ets  by  the  receiver  of  the  new  incarnation  of  the  connection. 

The  problem  is  that  the  recovering  host  may  not  know  for  how  long  it  crashed 
nor  does  it  know  whether  there  are  still  old  duplicates  in  the  system  form 
earlier  connection  incarnations. 

One  way  to  handle  these  situations  is  to  require  that  a  TCP  must  "keep  quiet", 
that  is,  refrain  from  emitting  segments,  for  a  maximum  segment  lifetime  (MSL) 
before  assigning  any  sequence  numbers.  This  quiet  time  restriction  allows  the 
segments  from  earlier  connection  incarnations  to  drain  from  the  network. 
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For  this  specification,  the  MSI  is  assumed  to  be  2  minutes.  This  is  an 
engineering  choice,  and  may  be  changed  as  experience  dictates.  TCP  implemen¬ 
tors  violating  this  restriction  run  the  risk  of  causing  some  old  data  to  be 
accepted  as  new  or  new  data  rejected  as  old  duplicates.  Note  that  if  a  TCP 
is  reinitialized  yet  retains  its  knowledge  of  sequence  numbers  in  use,  the 
quiet  time  restriction  does  not  apply;  however,  care  should  be  taken  to  use 
sequence  numbers  larger  than  those  recently  used. 


6.1.13  Resets 

One  of  the  control  flags  of  the  TCP  header  is  the  reset  flag.  A  segment  car¬ 
rying  a  reset  flag  set  true  is  called  a  reset.  Resets  are  used  to  to  abruptly 
close  established  connections,  refuse  connection  attempts,  and  respond  to 
segments  apparently  not  intended  for  the  current  incarnation  of  a  connection. 
The  following  paragraphs  define  the  rules  for  reset  generation  and  for  reset 
validation  and  processing. 

6.1.13-1  Reset  Generat i on  Each  paragraph  below  specifies  when  a  reset  should 
be  sent,  the  sequence  number  and,  when  needed,  the  acknowledgement  number 
necessary  to  make  the  reset  segment  acceptable  to  the  remote  TCP. 

When  either  ULP  of  the  communicating  ULP-pair  issues  an  Abort  service  request, 
its  local  TCP  informs  the  remote  TCP  with  a  reset  segment  carrying  a  sequence 
number  field  equal  to  SEN0_NEXT. 

As  a  general  rule,  reset  (RST)  must  be  sent  whenever  a  segment  arrives  which 
apparently  is  not  intended  for  the  current  connection,  A  reset  must  not  be 
sent  if  it  is  not  clear  that  this  is  the  case.  Specific  examples  of  reset 
generation  in  response  to  misdirected  segments  are  presented  in  three  groups 
of  states: 

1.  When  the  connection  does  not  exist  (i.e.,  its  state  is  CLOSED)  then  a 
reset  is  sent  in  response  to  any  incoming  segment  except  another  reset. 
In  particular,  SYNs  addressed  to  nonexistent  connections  are  rejected  in 
this  manner. 

If  such  an  incoming  segment  has  an  ACK  field,  the  reset  segment  takes  its 
sequence  number  from  the  ACK  field  of  the  incoming  segment;  otherwise, 
the  reset  segment  takes  a  sequence  number  value  of  zero  and  an  ack¬ 
nowledgement  number  equal  to  the  sum  of  the  sequence  number  and  text 
length  of  the  incoming  segment.  The  connection  remains  in  the  CLOSED 
state. 

2.  When  the  connection  is  in  any  nonsynchron i zed  state  (LISTEN,  SYN-SENT, 
SYN-RECE I VED) ,  a  reset  is  sent  in  the  following  cases:  The  incoming  seg¬ 
ment  acknowledges  something  not  yet  sent  (that  is,  the  segment  carries  an 
unacceptable  ACK),  or  an  incoming  segment  carries  security  information 
which  does  not  exactly  match  that  designated  for  the  connection. 


Resets  generated  in  the  nonsynchron i zed  states  are  made  acceptable  as 
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follows.  When  the  incoming  segment  has  an  ACK  field,  the  reset  segment 
takes  its  sequence  number  from  the  ACK  field  of  the  incoming  segment; 
otherwise,  the  reset  segment  carries  a  sequence  number  equal  to  2ero  and 
and  acknowledgement  field  set  to  the  sum  of  the  sequence  number  and  text 
length  of  the  incoming  segment.  The  connection  remains  in  the  same 
state. 

3.  If  the  connection  is  in  a  synchronized  state  (ESTABLISHED,  FIN-WAIT-1, 
FIN-WAIT-2,  CLOSE-WAIT,  CLOSING,  LAST-ACK,  TIME-WAIT),  any  unacceptable 
segment  (such  as  one  with  an  out  of  window  sequence  number  or  an  unac¬ 
ceptable  acknowledgement  number)  must  elicit  only  an  empty  acknowledge¬ 
ment  segment  containing  the  current  send  sequence  number  (SEND_NEXT)  and 
an  acknowledgement  indicating  the  next  sequence  number  expected  to  be 
received  (RECV_NEXT)  .  (Note  that  if  the  unacceptable  segment  is  an  empty 
ACK  segment,  replying  with  an  ACK  may  result  in  a  cascade  of  ACKs.  In 
general,  don't  ACK  an  unacceptable  empty  ACK  segment.)  The  connection 
remains  in  the  same  state. 

If  an  incoming  segment  has  security  information  or  a  precedence  level 
which  does  not  exactly  match  those  designated  for  the  connection,  a  reset 
is  sent;  the  connection  enters  the  CLOSED  state.  The  reset  segment  takes 
its  sequence  number  from  the  ACK  field  of  the  incoming  segment. 


6.1.13.2  Reset  Process i nq  In  all  states  except  SYN-SENT,  all  reset  (RST) 
segments  are  validated  by  checking  their  sequence  number  fields.  A  reset  is 
valid  if  its  sequence  number  is  in  the  connection's  receive  window.  In  the 
SYN-SENT  state  (a  RST  received  in  response  to  an  initial  SYN) ,  the  RST  is 
valid  if  the  ACK  field  acknowledges  the  SYN. 

The  receiver  of  a  RST  first  validates  it,  then  changes  state.  If  the  receiver 
was  in  the  LISTEN  state,  it  ignores  it.  If  the  receiver  was  in  SYN-RECEIVED 
state  and  had  previously  been  in  the  LISTEN  state,  then  the  receiver  returns 
to  the  LISTEN  state;  otherwise,  the  receiver  aborts  the  connection  and  goes  to 
the  CLOSED  state.  If  the  receiver  was  in  any  other  state,  it  aborts  the  con¬ 
nection  and  advises  the  ULP  and  goes  to  the  CLOSED  state. 
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6.2  TCP  HEADER  FORMAT 


A  summary  of  the  contents  of  a  TCP  header  follows: 


0  12  3 

O123l45678901231*56789012345678901 

|  Source  Port  j  Destination  Port  | 

|  Sequence  Number  | 

■\ — *— • +-+-+-+-H - 1 - 

|  Acknowledgement  Number  | 


Data 

U 

A 

P 

R 

S 

f 

Offset 

Reserved 

R 

C 

S 

S 

Y 

1 

Wi ndow 

G 

K 

H 

T 

N 

N 

[  Checksum  |  Urgent  Pointer  | 

— 4--+-+-+ — ♦—+-+—+■—+ — 

|  Options  |  [ 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+-+-+-4-+-+-+-+-+-+-+-+-+-+-+ 

I  I 

Data  | 

4—4 — +-+—+-+— +-4*—+— +—+■•“+— f— 4- — ^ — f- — h — — f — b — ¥ — ! — f — 4* — f- 4— 4—4— + 

TCP  Header  Format 

Note  that  each  tick  mark  represents  one  bit  position.  Each  field  description 
below  includes  its  name,  an  abbreviation,  and  the  field  size.  Where  applica¬ 
ble,  the  units,  the  legal  range  of  values,  and  a  default  value  appears. 


6.2.1  Source  Port 

abbrev:  SRC  PORT  field  size:  16  bits 
The  source  port  number. 


6.2.2  Destination  Port 

abbrev:  DEST  PORT  field  size:  16  bits 

The  destination  port  number. 


6.2.3  Sequence  Number 

abbrev:  SEQ  field  size:  32  bits 

units  :  octets  range  :  0  -  2**32- 1 


Usually,  this  value  represents  the  sequence  number  of  the  first  data  octet  of 
a  segment.  However,  if  a  SYN  is  present,  the  sequence  number  is  the  initial 


6  July  1982 


-96- 


System  Development  Corporation 
TM-7 172/482/00 


sequence  number  (ISN)  covering  the  SYN;  the  first  data  octet  is  then  numbered 
ISN+1 . 


6.2.4  Acknowl eqement  Number 

abbrev:  ACK  field  si2e:  32  bits 

units  :  octets  range  :  0  -  2**32- 1 

If  the  ACK  control  bit  is  set  this  field  contains  the  value  of  the  next 
sequence  number  that  the  sender  of  the  segment  is  expecting  to  receive. 


6.2.5  Data  Offset 

abbrev:  none  field  si2e:  4  bits 

units  :  32-bits  range  :  5  "  15  default  :  5 

This  field  indicates  the  number  of  32  bit  words  in  the  TCP  header.  From  this 
value,  the  beginn'ng  of  the  data  can  be  computed.  The  TCP  header  (even  one 
including  options)  is  an  integral  number  of  32  bits  long. 


6.2.6  Reserved 

abbrev:  none  field  si2e:  6  bits 

Reserved  for  future  use.  Must  be  set  to  2ero. 


6.2.7  Control  Flags 

abbrev:  below  field  si2e:  6  bits(from  left  to  right) 


URG:  Urgent  Pointer  field  significant 

ACK:  Acknowledgment  field  significant 

PSH:  Push  Function 

RST :  Reset  the  connection 

SYN:  Synchroni2e  sequence  numbers 

FIN:  No  more  data  from  sender 

These  flags  carry  control  information  used  for  connection  establishment,  con¬ 
nection  termination,  and  connection  maintenance. 


6.2.8  Window 

abbrev:  WNDW  field  si2e:  2  octets 

units  :  octets  range  :  0  -  2**l6-l  default  :  none 

The  number  of  data  octets  beginning  with  the  one  indicated  in  the  acknowledg¬ 
ment  field  which  the  sender  of  this  segment  is  willing  to  accept. 
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6.2.9  Checksum 

abbrev:  none  field  size:  2  octets 

The  checksum  field  is  the  16  bit  one's  complement  of  the  one's  complement  sum 
of  all  16  bit  words  in  the  header  and  text.  The  checksum  also  covers  a  96  bit 
pseudo  header  conceptually  prefixed  to  the  TCP  header.  This  pseudo  header 
contains  the  Source  Address,  the  Destination  Address,  the  Protocol,  and  TCP 
length.  The  checksum  algorithm  is  defined  in  section  6.1.5- 


6-2.10  Urgent  Pointer 

abbrev:  URGPTR  field  si2e:  2  octets 

units  :  octets  range  :  0  -  2**16- 1  default  :  0 

This  field  indicates  the  current  value  of  the  urgent  pointer  as  a  positive 
offset  from  the  sequence  number  in  this  segment.  The  urgent  pointer  points  to 
the  sequence  number  of  the  octet  following  the  urgent  data.  This  field  is 
only  be  interpreted  in  segments  with  the  URG  control  bit  set. 


6.2.11  Options 

abbrev:  OPT  field  size:  variable 


If  present,  options  orcupy  space  at  the  end  of  the  TCP  header  and  are  a  multi¬ 
ple  of  8  bits  in  length.  All  options  are  included  in  the  checksum.  An  option 
may  begin  on  any  octet  boundary. 

There  are  two  cases  for  the  format  of  an  option: 

1.  A  single  octet  of  option-kind. 

2.  An  octet  of  option-kind,  an  octet  of  opt i on- 1 ength ,  and  the  actual 
option-data  octets. 

The  option-length  counts  the  two  octets  of  option-kind  and  option-length  as 
well  as  the  option-data  octets.  Note  that  the  list  of  options  may  be  shorter 
than  t' v  ..eta  offset  field  might  imply.  The  content  of  the  header  beyond  the 
End-of-Opt ion  option  must  be  header  padding  (i.e.,  zero). 

Currently  defined  options  include  (kind  indicated  in  octal): 


Kind  Length  Meaning 


0 

1 

2 


End  of  opt  ion  list. 
No-Operation. 

I*  Maximum  Segment  Size. 
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+ - + 

1 00000000 | 

+ - + 

K i nd-0 

This  option  code  indicates  the  end  of  the  option  list.  This  might  not  coin¬ 
cide  with  the  end  of  the  TCP  header  according  to  the  Data  Offset  field.  This 

is  used  at  the  end  of  all  options,  not  the  end  of  each  option,  and  need  only 

be  used  if  the  end  of  the  options  would  not  otherwise  coincide  with  the  end  of 

the  TCP  header. 

6.2.11.1.2  No-Operat i on 

+ - + 

| 0000000 1 | 

+ - + 

Ki nd*1 

This  option  code  may  be  used  between  options,  for  example,  to  align  the  begin¬ 
ning  of  a  subsequent  option  on  a  word  boundary.  There  is  no  guarantee  that 

senders  will  use  this  option,  so  receivers  must  be  prepared  to  process  options 
even  if  they  do  not  begin  on  a  word  boundary. 


6.2.11.1.3  Maximum  Segment  Si2e 

+ - + - + - + - + 

|000000 10)00000 100 |  max  seg  size  | 

+ - + - + - + - + 

Kind-2  Length-i* 


If  this  option  is  present,  then 
receive  segment  size  at  the  TCP 
This  field  must  only  be  sent  in 
(i.e.,  in  segments  with  the  SYN 
If  this  option  is  not  used,  any 


it  communicates  the  maximum 
which  sends  this  segment, 
the  initial  connection  request 
control  bi t  set) . 
segment  size  is  allowed. 


6.2.12  Padding 

abbrev:  none  field  size:  variable 


The  padding  is  used  to  ensure 
bit  boundary.  The  padding  is 


that  the  TCP  header  ends  and  data  begins  on  a  32 
composed  of  zeros. 


r 

i 
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6.3  EXTENDED  STATE  MACHINE  SPECIFICATION  OF  TCP  ENTITY 

The  TCP  protocol  entity  is  specified  with  an  extended  state  machine  made  up  a 
of  set  of  states,  a  set  of  transitions  between  states,  and  a  set  of  input 
events  causing  the  state  transitions.  The  following  specification  is  made  up 
of  a  machine  instantiation  identifier,  a  state  diagram,  a  state  vector,  data 
structures,  an  event  list,  and  a  correspondence  between  events  and  actions. 
In  addition,  an  extended  state  machine  has  an  initial  state  whose  value  are 
assumed  at  state  machine  instantiation. 


6.3.1  Machine  Instantiation  Identifier 

One  state  machine  instance  exists  for  each  connection.  A  connection,  and 
hence  a  state  machine,  is  uniquely  named  by  either  of  the  two  machine  instan- 
tiat:on  identifiers  that  exist:  the  socket  pair  and  the  local  connection  name. 

6. 3. 1.1  Socket  Pa i r  I  dent i f i er  TCP  segments  delivered  by  the  network  and 
connection  establishment  service  requests  (Active  Open,  Active  Open  with  Data, 
Full  Passive  Open,  and  Unspecified  Passive  Open)  carry  and  thus  are  bound  to  a 
connection  with  the  following  values: 

o  source  address 

o  source  port 

o  destination  address 

o  destination  port 

6.3*1  * 2  Loca I  Connect i on  Name  A  TCP  entity  assigns  an  identifier,  a  local 
connection  name,  that  appears  in  all  service  responses  and  all  service 
requests  except  for  active  and  passive  open  requests. 

6.3.2  State  Diagram 

The  following  diagram  summarizes  the  state  machine  for  the  TCP  entity: 
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Active  Open  or  Unspecified  Passive  Open  or 

Active  Open  with  data  Fully  Specified  Passive  Open 

init  sv;  send  SYN  |  CLOSED  |  init  sv 

- >+=========+< - 


C I  ose 


Close 
clear  sv 

I 

recv  SYN  +== 


clear  sv 

v  I  !  v 

+====*===”■=+  recv  SYN  +====«====+  recv  SYN  +=======*=+ 

|  SYN  SENT  | - >  |  SYN  RECVD  |  < - |  LISTEN  | 

+■■***“*«+  send  SYN.ACK  +=========+  send  SYN.ACK  +====««==*+ 

I  \ 

recv  ACK  \ 
of  SYN  \ 
v  \ 

recv  SYN.ACK  +«==»=*===+  recv  FIN,  ACK  of  SYN 

- - - >|  ESTAB  |  - - — 

send  ACK  +=========+  \  send  ACK 


I 


CLOSE 


!  \ 

recv  FIN  \ 


\ 


send  FIN 

/ 

|F IN  WAIT1 | 

+bbbb=bbbb+— - ———————————— 

I  \  I 

recv  recv  FIN, ACK  recv  FIN 

ACK  of  FIN  - -  - 

|  send  ACK  send  ACK 


\ 


send  ACK 

\  v 

| CLOSEWA I T | 


+=« 


«  =  *=+ 


I 


|  FIN  WA I T2 | 

I 

recv  FIN 
send  ACK 


•fsasssssaaf 

|  CLOSING  | 
+==*=*====+ 

I 

recv  FIN, ACK 
send  ACK 


Close 

send  FIN 
v 

■+-BB5E*BBBBB-f> 

I  LAST  ACK I 

+SBBSBBBBB+ 

I 

recv 

ACK  of  FIN 


+»K«>na+  Timeout  +«=*«-«»+ 

->  (TIME  WA  I T  | . . >|  CLOSED  | 

+«■■■■■—+  (2  MSL)  +====■■==•=+ 


TCP  ENTITY  STATE  SUMMARY 


legend 

recv  -  NET_OELIVER  of  segment 
send  -  NET_SEND  of  segment 


sv  -  state  vector 
init  -  initialize 
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2  MSI  -  2  max  segment  lifetimes  clear  -  nullify 

Please  note  the  diagram  is  intended  only  as  a  summary  and  does  not  supersede 
the  formal  definition  that  follows. 


6.3-3  State  Vector 

The  elements  comprising  the  state  vector  of  a  TCP  entity  appear  below.  Each 

element  name  is  followed  by  by  the  name  of  the  corresponding  record  element 

in  the  state  vector  structure  “sv"  declared  in  Section  6.3.4. 1. 

1.  state  name  (sv. state) :  the  current  state  of  the  entity  state  machine  from 

the  following  list:  CLOSED,  LISTEN,  SYNRECVD,  SYN_SENT,  ESTAB, 

F I N_WA I T 1 ,  F I N_WA I T2 ,  CLOSE_WAIT,  CLOSING,  LAST~ACK ,  T I ME_WA IT. 

2.  source  address  (sv.source_addr) :  the  internet  address  naming  the  location 
of  the  local  ULP. 

3.  source  port  (sv . source_por t)  :  the  identifier  of  the  local  ULP. 

4.  destination  address  (sv .des t i nat i on_addr) :  the  internet  address  of  the 
location  of  the  the  ULP  at  the  other  end  of  the  connection. 

5-  destination  port  (sv.dest i nat ion_por t) :  the  identifier  of  the  ULP  at  the 
other  end  of  the  connection.  » 

6.  lcn  (sv.lcn):  local  connection  name,  the  identifier  associated  with  this 
end  of  the  connection. 

7.  open  mode  (sv.open  mode):  the  type  of  open  request  issued  by  the  local 
ULP,  either  ACTIVE  or  PASSIVE. 

8.  original  precedence  (sv .or i g i na l_pr ec) :  one  of  eight  levels  of  special 
handling  requested  by  the  local  ULP  in  the  open  request. 

9-  actual  precedence  (sv.actual_prec) :  one  of  eight  levels  of  special  han¬ 
dling  negotiated  during  connection  establishment  and  verified  throughout 
connection  lifetime. 

10.  security  (sv.sec) :  information  (including  security  level,  compartment, 
handling  restrictions,  and  transmission  control  code)  defined  by  the 
local  ULP. 

11.  ulp  timeout  (sv.u)p_timeout) :  the  maximum  delay  allowed  for  data 
transmitted  on  the  connection. 

12.  send  unacknowledged  sequence  number  (sv . send_una) :  oldest  unacknowledged 
send  sequence  number  (i.e.  left  edge  of  send  window). 

13-  send  next  sequence  number  (sv. send_next) :  sequence  number  of  the  next 
data  octet  to  be  sent. 
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14.  send  free  sequence  number  (sv. send_f ree) :  sequence  number  of  the  first 
free  octet  in  the  send  queue  (i .e.  the  next  octet  to  be  received  from  the 
local  ULP)  . 

15*  send  window  (sv . send_wndw) :  allowed  number  of  octets  that  may  be  sent  to 
the  remote  TCP  relative  to  the  send  unacknowledged  sequence  number. 

16.  send  urgent  sequence  number  (sv.send_urg) :  sequence  number  of  the  last 
octet  of  urgent  data  in  send  stream. 

17-  send  push  sequence  number  (sv . send_push) :  sequence  number  of  the  last 
octet  of  pushed  data  in  the  send  stream. 

18.  send  last  window  update  1  (sv.send_lastupl)  :  sequence  iber  of  the 

incoming  segment  used  for  last  window  update. 

19-  send  last  window  update  2  (sv . send_l astup2) :  acknowl edgmet  _mber  of  the 
incoming  segment  used  for  last  window  update. 

20.  send  initial  sequence  number  (sv . send_i sn) :  sequence  numb  the  origi¬ 

nal  SYN  sent. 

21.  send  fin  flag  (sv . send_f i nf 1 ag) :  indicates  that  the  local  ULP  has  issued 
a  Close  request. 

22.  send  maximum  segment  size  (sv . send_max_seg) :  maximum  sized  segment  to  be 
sent  to  the  remote  TCP  on  this  connection. 

23.  send  queue  (sv . send_queue) :  location  of  data  received  from  the  local  ULP 
and  either  awaiting  acknowledgement,  or  awaiting  transmission.  This  area 
is  accessed  only  by  the  data  management  routines. 

24.  receive  next  sequence  number  (sv . recv_next) :  sequence  number  of  next  data 
octet  expected  to  be  received. 

25-  receive  save  sequence  number  (sv. recv_next) :  sequence  number  of  next  data 
octet  to  be  delivered  to  the  local  ULP. 

26.  receive  window  (sv . recv_wndw)  :  allowed  number  of  data  octets  to  be 
received  from  the  remote  TCP  starting  with  the  receive  next  sequence 
number . 

27.  receive  alloc  (sv.recv_al loc) :  the  number  of  data  octets  will  to  be 
accepted  by  the  local  ULP. 

28.  receive  urgent  sequence  number  (sv.recv_urg) :  sequence  number  of  the  last 
octet  of  urgent  data  in  receive  stream. 


29-  receive  push  sequence  number  (sv , recv_push) :  sequence  number  of  the  last 
octet  of  pushed  data  in  receive  stream. 
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30.  receive  initial  sequence  number  (sv . recv_i sn) :  sequence  number  of  the  SYN 
received  from  remote  TCP. 

31.  receive  fin  flag  (sv . recv_f i nf 1 ag) :  indicates  that  fin  has  been  received 
from  the  remote  TCP. 

32.  receive  queue  (sv . recv_queue) :  location  of  data  accepted  from  remote  TCP 
before  delivery  to  local  ULP.  This  area  is  accessed  only  by  the  data 
management  routines. 

6.3.1*  Data  Structures 

The  TCP  entity  state  mach i ne  references  certain  data  areas  correspond i ng  to 
the  state  vector,  the  service  requests  and  responses  on  the  upper  interface, 
and  the  service  requests  and  responses  on  the  lower  interface.  For  clarity  in 
the  events  and  actions  section,  these  data  structures  are  declared  in  ADA. 
However,  a  data  structure  may  may  partially  typed  or  untyped  where  specific 
formats  or  data  types  are  implementation  dependent. 


6.3.1*.!  state  vector  The  TCP  entity  state  vector  is  defined  in  Section  6.3. 1 
above.  The  corresponding  structure  is  declared  as: 
sv  :  state_vector_type; 

type  state_vector_type  i s 
record 

state  :  (CLOSED,  LISTEN,  SYN_RECVD ,  SYN_SENT 
ESTAB,  F I N_WA I T 1 ,  F I N_WA I T2 , 

CLOSE_WAIT, CLOSING,  LAST_ACK ,  T I ME_WA I T)  ; 
source_addr  :  address_type ; 
source_port  :  TW0_0CTETS; 
dest i nat i on_addr  :  address_type; 
des t i nat i on_por t  :  TWO_OCTETS; 
lcn  :  integer: 

openjnode  :  (ACTIVE,  PASSIVE); 

or i g i na l_prec  :  precedence_type ; 

actual_prec  :  precedence_type; 

sec  :  secur i ty_type ; 

u!p_timeout  :  integer; 

send_una  :  sequence_number_type; 

send_next  :  sequence_number_type ; 

send_free  :  sequence_number_type ; 

send_wndw  :  integer; 

send_urg  :  sequence_i>umber_type ; 

send_push  :  sequence_number_type; 

send_lastupl  :  sequence_number_type; 

send_lastup2  :  sequence_number_type; 

send_isn  :  sequence_number_type ; 

send__f  i  nf  1  ag  :  boolean; 

send_max_seg  :  integer; 

send_queue  :  queue_type; 

recv_next  :  sequence_number_type; 

recv_save  :  sequence_number_type; 
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recv_wndw  :  integer; 
recv_alloc  :  integer; 
recv_urg  :  sequence_number_type; 
recv_push  :  sequence_number_type; 
recv_isn  :  sequence_number_type; 
recv_finflag  :  boolean; 
recv_queue  :  queue_type; 
end  record ; 


6. 3. 4. 2  from  U L P  The  from_ULP  structure  holds  the  service  request  parame.ers 
and  data  associated  with  the  service  request  primitives  as  specified  i  .  Sec¬ 
tion  3-1 • 1.  The  from_ULP  structure  is  declared  as: 

type  f rom_ULP_type  i s 
record 

request_name  :  (Unspec i f i ed_Pass i ve_0pen,  Ful l_Passive_Open, 

Active_Open,  Act i ve_0pen_wi th_data. 

Send,  Allocate,  Close,  Abort,  Status); 

source_addr 
source_port 
dest i nat i on_addr 
dest  i  nat  i  on__port 
I  cn 

ulp_timeout 

precedence 

security 

data 

data_! ength 
push_f lag 
urgent_f 1 ag 
end  record; 


6. 3.4. 3  to  ULP  The  to_ULP  structure  holds  service  response  parameters  and 
data  as  specified  in  Section  3>'-2.  Although  the  structure  is  composed  of  the 
parameters  from  all  the  service  requests,  a  particular  service  response  will 
use  only  those  structure  elements  corresponding  to  its  specified  parameters. 
This  structure  directly  corresponds  to  the  to_ULP  structure  declared  in 
3- 3-4. 3  of  the  upper  service  specification.  The  to_ULP  structure  is  declared 
as : 

type  to_ULP_type  i s 
record 

service  response  :  (OPEN  ID,  OPEN _ F  A I L,  OPEN  SUCCESS, 

DELIVER,  CLOSING,  TERMINATE,  ERROR); 

source_addr 

source_port 

dest i nat ion_addr 

destination_port 

1  cn 

data 
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data  length 
urgent_f 1 ag 
er ror_desc 

status_b!ock  :  status_block_type; 
end  record : 

type  status_b I ock_type  i s 
record 

connect i on_state 
send_wi ndow 
rece i ve_w i ndow 
amount_of_unacked_da ta 
amount_of_unrecei ved_data 
urgent_state 
precedence 
secur i ty 
ulp_timeout 
end  record : 


6. l.U.U  to  NET  The  to_NET  structure  holds  the  service  request  parameters  and 
data  associated  with  the  NET_SEND  service  request  specified  in  Section  5.1.1. 
This  structure  directly  corresponds  to  the  to_NET  structure  declared  in  5.2.2 
of  the  lower  layer  service  requirements  section.  The  to_NET  structure  is 
declared  as: 

type  to_NET_type  i s 
record 

source_addr 
dest i nat i on_addr 
protocol 

type_of_service  i s 
record 

precedence 

reliability 

delay 

throughput 
reserved 
end  record ; 
time_to_l ive 
dont_f ragment 
1 ength 

seg  :  segment_type; 
options 
end  record : 


6. 3. 4.5  from  NET  The  from_NET  structure  holds  the  service  response  parame¬ 
ters  and  data  associated  with  the  NET_DELIVER  service  response,  as  specified 
in  Section  5*^*2.  This  structure  directly  corresponds  to  the  from_NET  struc¬ 
ture  declared  in  5-2.3  of  the  lower  layer  service  requirements  section.  The 
from  NET  structure  is  declared  as: 
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type  f rom_N£T_type  i s 
record 

source_addr 
dest i nat i on_addr 
protocol 

type_of_service  i  s 
record 

precedence 
reliability 
de  I  ay 

throughput 
reserved 
end  record ; 

1 ength 

seg  :  segment_type; 

opt i ons 

error 

end  record; 


6. 3-^-6  segment  type  A  segment_type  structure  holds  a  TCP  segment  made  up  of 
a  header  portion  and  a  data  portion  as  specified  in  Section  6.2.  A 
segment_type  structure  is  declared  as: 

type  segment_type  i s 
record 

source_port  :  TW0_0CTETS; 

dest i nat i on_port  :  TW0_0CTETS; 
seq_num  :  F0UR_0CTETS; 

ack_num  :  FOUR  OCTETS; 

data_of f set  ;  HALF_0CTET ; 
reserved  :  S I X_E I GHTHS_0CTET ; 
urg_flag  :  0NE_BIT; 
ack_f 1 ag  :  0NE_B I T ; 
push_flag  :  0NE_BIT; 
rst_flag  :  0NE_B!T; 
syn_flag  :  ONE  BIT; 
f i n_f 1 ag  :  0NE~BIT; 
wndw  :  TWO^OCTETS; 

checksum  :  TWO_OCTETS; 

urgptr  :  TW0_0CTETS; 

options  :  is  array  of  OCTET; 

padding  :  is  array  of  OCTET; 

data  :  is  array  of  OCTET; 

end  record ; 

6 . 3 • ^ * 7  Supplemental  Type  Dec  1 arat i ons 

type  address_type  is  F0UR_0CTETS; 
type  sepuence_number_type  is  F0UR_0CTETS; 
type  precedence_type  is  INTEGER  range  0..7; 
type  secur  i  ty_type  j_s 
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record 

secur i t y_ 1 evel  :  HALF_OCTET; 
compartment  :  TWO  OCTETS; 
handling  :  TWO~OCTETS; 

trans_control_code  :  THREE_0CTETS; 
end  record ; 

subtype  OCTET  is  INTEGER  range  0..255; 
subtype  HALF_0CTET  is  INTEGER  range  0..15; 
subtype  F I VE~E I GHTHS_OCTET  is  INTEGER  range  0..31; 
subtype  TW0_0CT£TS  is  INTEGER  range  0.. 2**1 6-1; 
subtype  THREE_OCTETS  is  INTEGER  range  0.. 2**24-); 
subtype  F0UR_0CTETS  is  INTEGER  range  0.. 2**32- 1; 

NUIL_RESERVED  :  constant  FIVE  EIGHTHS  OCTET  :«  0; 

OPT  1 0NIESS_HE ADER  :  constant  INTEGER  :=  5? 

NORMAL  :  constant  INTEGER  :=  0; 

NULL  :  constant  INTEGER  :=  0; 

— NULL  assumed  to  be  outside  the  sequence  number  space. 
DEFAULT_PRECEDENCE  :  constant  INTEGER  :=  0; 

DEF AULT_SECUR I TY  ;  constant  INTEGER  :=  0; 

DEFAULT_T I MEOUT  :  constant  INTEGER  0111 1000  (8) ; 

0NE_M I NUTE_TTL  :  constant  INTEGER  :=  00111100(8); 

THIS_ADDRESS  :  constant  INTEGER;  --imp!,  dependent 

TCP_ID  :  constant  INTEGER;  --reference  [5] 


6.3.5  Event  List 

The  events  for  the  TCP  entity  state  machine  are  drawn  from  the  service  request 
primitives  defined  in  the  service  definition  of  Section  3.1.  Optional  service 
request  parameters  are  shown  in  brackets.  The  capitalized  list  of  parameters 
represent  the  actual  values  of  the  parameters  passed  by  the  service  primitive. 
The  event  list: 

1.  Unspecified  Passive  Open  (  SOURCE  PORT, 

[.TIMEOUT]  [.PRECEDENCE]  [.SECURITY]  ); 

2.  Full  Passive  Open  (  S0URCE_P0RT, 

DEST I  NAT  I 0N_P0RT,  DEST I  NAT  I ON_ADDRESS, 

[.TIMEOUT]  [.PRECEDENCE]  [.SECURITY]  ); 

3.  Active  Open  (  SOURC£_PORT, 

DESTINATION  PORT,  DESTINATION  ADDRESS 
[.TIMEOUT]  [.PRECEDENCE]  [.SECURITY]  ); 

4.  Active  Open  w/data(  S0URCE_P0RT, 

DESTINATION  PORT,  DESTINATION  ADDRESS 
[.TIMEOUT]  X. PRECEDENCE]  [.SECURITY]  ); 

DATA,  DATA_LENGTH,  PUSH_F LAG ,  URGENT_FLAG  ); 

5.  Send  (  LCN,  DATA,  DATA_LENGTH,  PUSH_FLAG,  URGENT_F LAG  [.TIMEOUT]  ); 
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6.  A! locate (  LCN,  OATA_L£NGTH  ) 

7.  Close  (  LCN  ) 

8.  Abort  (  LCN  ) 

9 •  Status  (  LCN  ) 

10.  NET_DEL I VER  (S0URCE_AD0RESS ,  DEST I  NAT  I ON_ADDRESS ,  PROTOCOL, 

TOS [precedence,  reliability,  delay,  throughput], 
OPT  I ONS  [secur i ty] ,  LENGTH,  DATA) 

r 

11.  Retransmission  Ti.neout 

12.  ULP  Timeout 

13-  Time  Wait  Timeout 


6.3.6  Events  and  Actions 

This  section  is  organized  in  three  parts,  ’’"he  first  part  contains  a  decision 
table  representation  of  state  machine  events  and  actions.  The  decision  tables 
are  organized  by  state;  each  table  corresponds  to  one  event. 

The  second  part  specifies  the  decision  functions  appearing  at  the  top  of  each 
column  of  a  decision  table.  These  functions  examine  attributes  of  the  event 
and  the  state  vector  to  return  a  set  of  decision  results.  The  results  become 
the  elements  of  each  column. 

The  third  part  specifies  action  procedures  appearing  at  the  right  of  every 
row.  Each  row  of  the  decision  table  combines  the  decision  results  to  deter¬ 
mine  appropriate  event  processing.  These  procedures  specify  event  processing 
a  1 gor i thms  i n  deta i I  . 

6.3.6. 1  Dec i s ion  Tables  The  Status  event  can  occur  in  any  state  except 
closed;  TCP's  action  is  to  return  the  current  state_vector  information  as 
specified  in  the  STATUS_RESPONSE  service  response. 

If  the  primary  state  vector  element  is  not  changed  in  the  decision  table  row 
corresponding  to  an  event,  the  "primary"  state  remains  unchanged. 


The  checksum  is  assumed  to  be  computed  for  all  incoming  segments.  When  the 
computed  checksum  does  not  match  the  igment's  header  checksum  field,  the  seg¬ 
ment  is  discarded  without  being  acknowledged. 
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STATE  *  CLOSED  Legend 

d  *  "don't  care"  condition 

Event:  Active  Open  (LOCAL  PORT,  REMOTE  PORT,  REMOTE_ADDRESS 
[TIMEOUT]  [PRECEDENCE]  [SECURITY]  ) 

Actions: 


Resources 

Sec 

suf  f  i  c 

prec 

— 

0 

■0 

ft 

D 

a  1 1  owed 

|  NO 

d 

error  ("Insufficient  resources.") 

|  YES 

NO 

error  ("Secur i ty/precedence  not  allowed.") 

|  YES 

YES 

open;gen_syn  (ALONE)  ;  sv.  state*=SYN_SENT 

Event:  Active  Open  with  Data (L0CAL_P0RT,  REM0TE_P0RT,  REMOTE  ADDRESS, 

[TIMEOUT]  [PRECEDENCE]  [SECURITY] 

DATA,  DATAJ.ENGTH,  PUSH_F LAG ,  URGENT_F LAG  ) 

Actions: 


siiCB«asK=se=csss=s3 


Resources 

Sec 

suf  f  i  c 

prec 

open? 

a  1 1  owed 

■smaeaBsasssazassas: 

= 

|  NO 

d 

error  ("Insufficient  resources.") 

|  YES 

NO 

error  ("Secur i ty/precedence  not  allowed.") 

|  YES 

YES 

open;gen_syn (WITH_DATA) ; sv. state=SYN_SENT 

Event:  Full  Passive  Open  (LOCAL  PORT,  REMOTE_PQRT,  REMOTE  ADORESS, 

[TIMEOUT]  [PRECEDENCE]  [SECURITyJ  ) 

Actions: 


Resources 

Sec 

suf f i c 

prec 

open? 

a  1 1  owed 

|  NO 

1  d 

| error  (" 1 nsuf f i c i ent  resources .") 

|  YES 

|  NO 

|  error  ("Secur i ty/precedence  not  allowed.") 

I  YES 

I  YES 

lopen;  sv.state-LISTEN 
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STATE  -  CLOSED  (con't) 


Event:  Unspecified  Passive  Open  (L0CAL_P0RT,  [TIMEOUT] 

[PRECEDENCE]  [SECURITY]  ) 

Act i ons : 


Resources 
suf  f  i  c 
open? 

Sec 
prec 
a  1 1  owed 

|  NO 

d 

error 

("Insufficient  resources.") 

|  YES 

NO 

error 

("Secur i ty/precedence  not  allowed.") 

|  YES 

YES 

open; 

sv.state**L  1  STEN 

Event:  Send  () 

or  Close  0 
or  Abort  () 
or  A 1  locate  () 

Actions:  error  ("Connect i on  does  not  exist.") 


Event:  NET_DEL i VER  (SOURCE  ADDRESS,  DESTINATION  ADDRESS,  PROTOCOL, 

TOS[precedence,  reliability,  delay,  throughput], 
OPT  I ONS [secur i ty] ,  LENGTH,  DATA) 

Actions: 


RST 

ACK 

on? 

on? 

|  NO 

NO 

reset  (SEG) 

|  NO 

YES 

reset (SEG) 

|  YES 

d 

--  no  action 
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STATE  <*  LISTEN 

Event:  Close  (  LCN  ) 

or  Abort  (  LCN  ) 

Actions:  reset_se 1 f (UC)  ;  sv.state-CLOSED 

Event:  A1 locate  (  LCN,  DATA_LENGTH  ) 
Actions:  new_a 1 locat i on 

Event:  Send  () 

Actions:  er ror  (" I  1 1 ega 1  request.") 


Event:  Active  Open  () 

or  Active  Open  with  data  () 
or  Full  Passive  Open  () 
or  Unspecified  Passive  Open  () 

Actions:  error  ("Connect i on  already  exists.") 


Event:  NET_DEL I VER  (SOURCE  ADDRESS,  DESTINATION  ADDRESS,  PROTOCOL, 

TOS [precedence,  reliability,  delay,  throughput], 
OPT  1 ONS [secur i ty] ,  LENGTH,  DATA) 

Actions: 


RST 

on? 

ACK 

on? 

■■msss 

SYN 

on? 

ccsaccsss 

Sec 

match? 

sv  prec 

vs 

seg  prec 

|  NO 

NO 

NO 

1  d 

d 

| —  no  action 

|  NO 

NO 

YES 

|  NO 

d 

| reset  (SEG) 

NO 

NO 

YES 

YES 

GREATER 

record_syn; gen_syn (WITH_ACK) 

or  EQUAL 

sv.state-SYN_RECVD 

NO 

NO 

YES 

YES 

LESS 

record  syn;  raise_prec; 

gen_syn (WITH_ACK) ;sv.state*SYN_RECVD 

|  NO 

YES 

d 

1  d 

d 

| reset (SEG) 

|  YES 

d 

d 

1  d 

d 

|--  no  action 
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STATE  *  SYN_SENT 

BSSSSSSS*B33SSSS 

Event:  Close(  LCN  ) 

or  Abort  (  LCN  ) 

Actions:  reset  self  (UC) :  sv.state=CLOSED 


Event:  Send  (  LCN,  OATA,  DATA_LENGTH,  PUSH_F LAG ,  URGENT_F LAG  [TIMEOUT]  ) 
Actions: 


Resources 
suf f  i  c 
send? 

NO  j error  (" I nsuf f i c ient  resources.”) 
YES  | save_send_data 


Event:  A1 locate  (  LCN,  OATA_LENGTH  ) 

Actions:  new_al location 

Event:  Active  Open  0 

or  Active  Open  with  data  () 
or  Full  Passive  Open  () 
or  Unspecified  Passive  Open  () 

Actions:  error  ("Connect i on  already  exists.") 

Event:  Retransmi sson  Timeout 

Actions:  retransmit 

Event:  ULP  Timeout 

Actions:  open_fail;  sv.state^CLOSED 
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STATE  -  SYN_SENT  (con't)  Legend 

d  *>  "don't  care"  condition 

Event:  NET_DEL I VER (SOURCE  ADDRESS,  DESTINATION  ADDRESS,  PROTOCOL, 

TOS [precedence ,  reliability,  delay,  throughput], 
OPTIONS  [secur i ty] ,  LENGTH,  DATA) 

Actions: 


ACK 

status 
test  1 

RST 

on? 

Sec 

match? 

ias4sa«ss< 

sv  prec 

vs 

seg  prec 

■xsaasi 

SYN 

on? 

iszxaa: 

FIN 

on? 

|  NONE  |  NO 

NO 

d 

d 

d 

reset  (SEG) 

|  NONE 

NO 

YES 

d 

NO 

d 

--  no  action 

NONE 

NO 

YES 

GREATER 
or  EQUAL 

YES 

NO 

record_syn;  send_ack (sv. recv_i sn+1) 
sv .  state=SYN_RECVD 

NONE 

NO 

YES 

GREATER 
or  EQUAL 

YES 

YES 

record_syn;  send_ack (sv. recv_i sn+1) 
save_fin;  sv.state=SYN_RECVD 

NONE 

NO 

YES 

LESS 

YES 

NO 

record_syn;  raise_prec; 
send_ack  (sv.recv_i sn+1) 
sv.state=:SYN_RECVD 

NONE 

NO 

YES 

LESS 

YES 

YES 

record_syn;  raise_prec 
send_ack  (sv. recv_i sn+1)  ; save_f i n 
sv . state=SYN_RECVD 

|  NONE 

YES  |  d 

d 

d 

d 

--  no  action 

|  INVAL 

NO 

d 

d 

d 

d 

reset  (SEG) 

| INVAL 

YES 

d 

d 

d 

d 

--  no  action 

|  VAL  1  D 

NO 

NO 

d 

d 

d 

reset  (SEG) 

|  VAL  1  D 

NO 

YES 

GREATER 

d 

d 

reset  (SEG) 

VALID 

NO 

YES 

LESS 

or  EQUAL 

NO 

raj 

—  no  action 

■ 

NO 

YES 

LESS 

or  EQUAL 

YES 

NO 

rai se_prec;conn_open 
sv.state-ESTAB 

■ 

NO 

YES 

LESS 

or  EQUAL 

YES 

YES 

raise_prec;  conn_open 
set_f i n; sv . state-CLOSE_WA IT 

|VALID  |  YESj  d  j  d  |  d  j  d  |openfai 1 ; sv.state-CLOSED 
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STATE  *  SYN_RECVD 

SSSS=====S=S3==== 

Event:  Close  {  LCN  ) 

Actions:  send_fin;  sv.state=F IN_WAIT1 
Event:  Abort  (  LCN  ) 

Actions:  reset  (CURRENT)  ;  reset_se 1 f  (UA) ;  sv . state«CL0SED 

Event:  Send  (  LCN,  DATA,  DAT A_LENGTH ,  PUSH_F L AG ,  URGENT_FLAG  [TIMEOUT]  ) 
Actions: 

BSSUailBH 

Resources 
suf f  i  c 
send? 

|  NO  |  error  (" I nsuf f i c i ent  resources.") 

|  YES  |  save_send_data 


Event:  A1 locate  (  LCN,  OATA_LENGTH  ) 

Actions:  new_a I  1 ocat i on 

Event:  Active  Open  () 

or  Active  Open  with  data() 
or  Full  Passive  Open  () 
or  Unspecified  Passive  Open  () 

Actions:  error ("Connect i on  already  exists.") 

Event:  Retransmission  Timeout 

Actions:  retransmit 

Event:  ULP  Timeout 

Actions:  reset  (CURRENT)  ;  openfail:  sv.state**CLOSED 


i 


6  July  1982 


-115- 


System  Development  Corporation 
TM-7 172/482/00 


STATE  =*  SYN_RECVD  (con't)  Legend 

d  ■  "don't  care"  condition 

Event:  NET_DEL I VER  (SOURCE  ADDRESS,  DESTINATION  ADDRESS,  PROTOCOL, 

TOS [precedence,  reliability,  delay,  throughput], 
OPT  I ONS  [secur i ty] ,  LENGTH,  DATA) 

Actions: 


Seq# 

OXBBI 

RST 

iniHii 

Sec 

E38SBB1 

Open 

ICS&SBl 

SYN 

:c:s3zaoi 

ACK 

Zero 

FIN 

status 

on? 

prec 

Mode 

i  n 

status 

recv 

seen? 

7 

Exaaa: 

match? 

7 

wndow 

test  1 

wndow 

|  INVAL 

NO 

d 

d 

d 

d 

d 

d 

send_ack (sv.recv_next) 

|  INVAL 

YES 

d 

d 

d 

d 

d 

d 

--  no  action 

VALID 

NO 

NO 

PASS 

d 

d 

d 

d 

reset  (SEG) ;  part_reset 
sv.state“L 1 STEN 

VALID 

NO 

NO 

ACT 

d 

d 

d 

d 

reset  (SEG) ; openf a  i  1 
sv.state«CLOSED 

|  VAL  1  D 

NO 

YES 

d 

NO 

NONE 

d 

d 

--  no  action 

|  VALID 

NO 

YES 

d 

NO 

INVAL 

d 

d 

reset  (SEG) 

|  VAL  ID 

NO 

YES 

a 

NO 

VALID 

NO 

NO 

conn_open; sv.state«ESTAB 

B 

NO 

YES 

d 

NO 

VALID 

NO 

YES 

conn_open;  set_fin 
sv.state-CLOSE_WAIT 

|  VAL  ID 

NO 

YES 

d 

NO 

VALID 

YES 

d 

update;  check_urg 
sv.state^ESTAB 

VALID 

NO 

YES 

d 

YES 

d 

d 

d 

reset  (SEG) jopenfai  1 
sv.state-CLOSED 

|  VAL  ID 

to 

Ui 

>- 

d 

PASS 

d 

d 

d 

d 

part_reset; sv.state»L 1 STEN 

|  VAL  ID 

YES 

ACT 

a 

d 

d 

d 

openfai 1 ; sv. state-CLOSED 
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STATE  =  ESTAB 

sissssssnus 

Event:  Close  (  LCN  ) 

Actions:  send_fin;  sv . s tate=F I N_WA I T1 
Event:  Abort  (  LCN  ) 

Actions:  reset  (CURRENT)  ;  reset_se 1 f  (UA) ;  sv. state=CL0SED 

Event:  Send  (  LCN,  DATA,  DATA_LENGTH ,  PUSH_F LAG ,  URGENT_F L AG  [TIMEOUT]  ) 
Actions: 

■  aesasmsH 

Resources 
suf f  i  c 
send? 

|  NO  | error  (" I nsuf f i c i ent  resources.") 

|  YES  [dispatch 


Event:  A1 locate  (  LCN,  DATA_LENGTH  ) 

Actions:  new_al location 

Event:  Active  Open  () 

or  Active  Open  with  data() 
or  Full  Passive  Open  () 
or  Unspecified  Passive  Open  () 

Actions:  error ("Connect i on  already  exists.") 

Event:  Retransmission  Timeout 

Actions:  retransmit 

Event:  ULP  Timeout 

Actions:  reset  (CURRENT)  ;  reset_se 1 f  (UT) ;  sv . state“CL0SED 
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STATE  =  ESTAB  (con't)  Legend 

========*============  d  =  "don't  care"  condition 

Event:  N£T_DE L I VER  (SOURCE  ADDRESS,  DESTINATION  ADDRESS,  PROTOCOL, 

TOS [precedence,  reliability,  delay,  throughput], 
OPT  I ONS  [secur i ty] ,  LENGTH,  DATA) 

Actions: 


Seq# 

status 

7 

RST 

on? 

Sec 

prec 

match? 

SYN 
i  n 

wndow 

ACK 

status 

test2 

Zero 

recv 

wndow 

FIN 

seen? 

|  INVAL 

NO 

d 

d 

d 

d 

d 

send_ack  (sv . recv_next) 

| INVAL 

YES 

d 

d 

d 

d 

d 

—  no  action 

VALID 

NO 

NO 

d 

d 

d 

d 

reset  (SEG) ;reset_self (SP) 
sv.state=CLOSED 

(VALID 

NO 

YES 

NO 

NONE 

d 

d 

--  no  action 

(VALID 

NO 

YES 

NO 

INVAL 

d 

d 

send_aek  (sv . recv_next) 

1 VAL  1  D 

NO 

YES 

NO 

VALID 

NO 

NO 

update; accept 

VALID 

NO 

YES 

NO 

VALID 

NO 

YES 

update;accept;set_f i n 
sv.state=CLOSE_WA IT 

|  VAL  1  D 

NO 

YES 

NO 

VALID 

YES 

d 

update; check_urg 

VALID 

NO 

YES 

YES 

d 

d 

d 

reset  (SEG) ; reset_se If (SF) 
sv.state=CLOSED 

|  VAL  ID 

YES 

d 

* 

d 

d 

d 

reset_se 1 f (RA)  ; sv . state=CLOSED 
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STATE  -  CLOSE  WAIT 


Event:  Send  (  LCN ,  DATA,  DATA_LENGTH,  PUSH_F LAG ,  URGENT_F LAG  [TIMEOUT]  ) 

Actions: 

Resources 
suf  f  i  c 
send? 

j  NO  |  error  (" I nsuf f i c i ent  resources.") 

|  YES  |  dispatch 

Event:  A1 locate  (  LCN,  OATAJ.ENGTH  ) 

Actions:  new_al location 

Event:  Active  Open  ()  * 

or  Active  Open  with  data  () 
or  Full  Passive  Open  () 
or  Unspecified  Passive  Open  () 

Actions:  error ("Connection  already  exists.") 

Event:  Close(  LCN  ) 

Actions:  send_fin;  sv.state«*LAST_ACK 

Event:  Abort  (  LCN  ) 

Actions:  reset (CURRENT) ;  reset_se 1 f  (UA) ;  sv.state»CLOSED 

Event:  Retransmission  Timeout 
Actions:  retransmi t 

Event:  ULP  Timeout 

Actions:  reset  (CURRENT) ;  reset_sel f  (UT) ;  sv . s tate»CLOSED 
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sussacssssessssssssssssss 

STATE  =  CL0SE_WA 1 T  (con't) 

Bsssssas:s=ss=s:3c:s«sssss 

Leqend 

d  =  "don't  care"  condition 

Event:  NET_OEL I VER  (SOURCE  ADDRESS,  DESTINATION  ADDRESS,  PROTOCOL, 

TOS [precedence ,  reliability,  delay,  throughput], 
OPT  I ONS  [secur i ty]  ,  LENGTH,  DATA) 

Actions: 


esbxs=e: 

Seq# 

status 

* 

ce==sss: 

j 1 NVAL 

33=s=a: 

RST 

on? 

NO 

SSBBSSl 

Sec 

prec 

match? 

d 

tsscss: 

SYN 
i  n 

wndow 

d 

ACK 

status 

test2? 

d 

s 

send_ack  (sv.recv_next) 

|  INVAL 

YES 

d 

d 

d 

-*•  no  action 

[VALID 

NO 

NO 

d 

d 

reset  (S EG) ;reset_sel f (SP)  ;sv.state“CLOSED 

(VALID 

NO 

YES 

NO 

NONE 

--  no  action 

[VALID 

NO 

YES 

NO 

INVAL 

send_ack (sv . recv_next) 

|  VAL  1  D 

NO 

YES 

NO 

VALID 

update 

|  VAL  1  D 

NO 

'ES 

YES 

d 

reset  (SEG) ;reset_self (SF) ;sv.state=CLOSED 

[VALID 

YES 

<* 

d 

d 

reset_sel f  (RA) ;  sv . state=CLOSED 
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STATE  =  CLOSING 

ssssaaaassssssB 

Event:  A 1  I ocate  (LCN ,  DATA_LENGTH) 

Act i ons :  new_a 1 1 ocat i on 

Event:  Send  () 

or  CloseO 

Actions:  erro-  ("Connection  closing.") 

Event:  Active  Open  () 

or  Active  Open  with  data() 
or  Full  Passive  Open  () 
or  Unspecified  Passive  Open  () 

Actions:  error  (Connect i on  already  exists.") 

Event:  Abort  (  LCN  ) 

Actions*,  reset  (CURRENT)  ;  reset_sel f (UA) ■  sv.state*CLOSED; 

Event:  Retransmission  Timeout 

Actions,  retransmit 

Event:  ULP  Timeout 

Actions:  reset  (CURRENT) ;  reset  self(UT);  sv . s ta te=CL0SED 
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STATE  =  CLOSING  (con't)  Legend 

========»===»=*========  d  *  “don't  care"  condition 

Event:  NET_DEL I VER (SOURCE  ADDRESS,  DESTINATION  ADDRESS,  PROTOCOL, 

TOS [precedence,  reliability,  delay,  throughput], 
OPT  I ONS  [secur i ty] ,  LENGTH,  DATA) 

Act i ons : 


Seq# 
s  tatus 

7 

RST 

on? 

Sec 

prec 

match? 

SYN 

I  n 

wndow 

ACK 

status 

test2? 

FIN 

ACK'd 

7 

■ 

|  INVAL 

NO 

d 

d 

d 

d 

send_ack  (sv . recv_next) 

| INVAL 

YES 

d 

d 

d 

d 

no  action 

[VALID 

NO 

NO 

d 

d 

d 

reset  (SEG) ;reset_self (SP) 
sv.state«CLOSED 

|  VALID 

NO 

YES 

NO 

NONE 

--  no  action 

|  VAL  1  D 

NO 

YES 

NO 

INVAL 

* 

send_ack  (sv .  recv_next) 

|  VAL  1  D 

NO 

YES 

NO 

O 

_l 

> 

NO 

update 

|  VAL  1  D 

NO 

YES 

NO 

VALID 

YES [star t_time_wai t ; sv . s tate=T 1 ME_WA 1 T 

VALID 

NO 

YES 

YES 

d 

d 

reset  (SEG) ; reset_sel f (SF) 
sv .  state-CLOSED 

|  VAL  ID 

YES  |  d 

0 

a 

reset_sel f  (RA) ;  sv.state“CLOSED 
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STATE  =*  F  I  N_WA  I  T 1 

Event:  Allocate!  LCN ,  DATAJ.ENGTH  ) 

Actions:  new_al location 

Event:  Send  () 

or  Close!) 

Actions:  error  ("Connect i on  closing.") 

Event:  Active  Open!) 

or  Active  Open  with  data!) 
or  Full  Passive  Open!) 
or  Unspecified  Passive  Open!) 

Actions:  error  ("Connect i on  already  exists.") 

Event:  Abort  (  LCN  ) 

Actions:  reset  (CURRENT)  ;  reset__se  1  f  (UA)  ;  sv.state»CLOSED 

Event:  Retransmission  Timeout 
Actions:  retransmit 

Event:  ULP  Timeout 

Actions:  reset  (CURRENT) ;  reset  self(UT);  sv . state=CLOSED 
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STATE  =  FIN_WAIT1  (con't)  Legend 

*>»«*«.*»*».*»*»«*»=  d  ■  "don't  care"  condition 

Event:  N£T_DE L I VER  (SOURCE  ADDRESS,  DESTINATION  ADDRESS,  PROTOCOL, 

TOS [precedence ,  reliability,  delay,  throughput], 
OPT  I ONS [secur i ty] ,  LENGTH.  DATA) 

Act i ons ; 


Seq# 

status 

7 

XXIZXIISI 

1 INVAL 

RST 

on? 

csssaz 

NO 

Sec 

prec 

match? 

:sssss«a 

d 

IZXZSBI 

SYN 

. 

1  n 

wndow 

tBSCZBl 

d 

ACK 

sta  wus 

tes  t2? 

[IlOXBEt 

d 

EZM«E1 

Zero 

recv 

wndow 

:x8a=c: 

d 

FIN 

ACK'd 

7 

d 

F  IN 
on? 

:cszs: 

d 

send_ack (sv . recv_next) 

| INVAL 

YES 

d 

d 

d 

d 

d 

d 

--  no  action 

VALID 

NO 

NO 

d 

d 

d 

d 

d 

reset: reset_sel f (SP) 
sv.state=*CLOSED 

|  VAL  1  D 

NO 

YES 

NO 

NONE 

d 

d 

d 

--  no  action 

{VALID 

NO 

YES 

NO 

INVAL 

d 

d 

d 

send_ack (sv . recv_next) 

J  VAL  1  D 

NO 

YES 

NO 

VALID 

NO 

NO 

NO 

update;accept 

VALID 

NO 

YES 

NO 

VALID 

NO 

NO 

YES 

update; accept ; set_f i n 
sv.state=CL0S 1 NG 

VALID 

NO 

YES 

NO 

VAL  10 

NO 

YES 

NO 

update; accept 
sv.state=F IN_WAIT2 

VALID 

NO 

YES 

NO 

VALID 

NO 

YES 

YES 

update; accept ; set_f i n 
start_time_wai t 
sv.state«'TIME_WAIT 

|  VAL  ID 

NO 

YES 

NO 

VALID 

YES |  NO 

d 

update 

|  VAL  ID 

NO 

YES 

NO 

VALID 

YES |  YES 

d 

update ;sv.state*F IN_WAIT2 

VALID 

NO 

YES 

YES 

d 

d 

d 

d 

reset  (S EG) ; reset_sel f  (SF) 
sv.state«CLOSED 

VALID 

YES 

d 

d 

d 

d 

d 

d 

reset_se 1 f (RA)  ; 
sv.state*CLOSED 
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STATE  *  F I N_WA 1 T2 

Event:  Abort  (  LCN  ) 

Actions:  reset  (CURRENT) ;  reset_sel f  (UA) ;  sv. state=CL0SED 

Event:  Allocate  (  LCN,  DAT  A_LENGTH  ) 

Actions:  new_al location 

Event:  Send  () 

or  Close  () 

Actions:  error ("Connect i on  closing.") 

Event:  Active  Open  () 

or  Active  Open  with  data() 
or  Full  Passive  Open  () 
or  Unspecified  Passive  Open  () 

Actions:  error  ("Connect  ion  already  exists.") 

Event:  Retransmission  Timeout 

Actions:  retransmit 

Event:  ULP  Timeout 

Actions:  reset (CURRENT) ;  reset_se 1 f  (UT) ;  sv . state*»CL0SED 


L 
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Legend 

d  =  "don't  care"  condition 

Event:  NET_DEL I VER  (SOURCE  ADDRESS,  DESTINATION  ADDRESS,  PROTOCOL, 

TOS [precedence ,  reliability,  delay,  throughput], 
OPT  IONS  [security],  LENGTH,  DATA) 

Act i ons : 


*SBSBSBS>XBSS«XSXSXeXCSXSC=SS=323C33B£ZSSSaaBK 


Seq# 

RST 

Sec 

SYN 

ACK 

Zero 

FIN 

status 

on? 

prec 

i  n 

status 

recv 

on? 

7 

1 

match?  j 

wndow 

test2? 

wndow 

|  INVAL 

NO 

d 

d 

d 

d 

d 

send_ack  (sv . recv_next) 

|  INVAL 

YES 

d 

d 

d 

d 

d 

--  no  action 

j  VALID 

NO 

NO 

d 

d 

d 

d 

reset (SEG) ;reset_sel f (SP) 
sv .  state«=CLOSED 

|  VALID 

NO 

YES 

NO 

NONE 

d 

d 

--  no  action 

|  VALID 

NO 

YES 

NO 

INVAL 

d 

d 

send_ack (sv . recv_next) 

|  VAL  1  D 

NO 

YES 

NO 

VALID 

NO 

NO 

update;accept 

VALID 

NO 

YES 

NO 

VAL  10 

NO 

YES 

update; accept; set_f i n 
start_t ime_wa i t 
sv . s tate*T 1 ME_WA 1 T 

|  VAL  1  D 

NO 

YES 

NO 

VALID 

YES 

d 

update 

VAL !  0 

NO 

YES 

YES 

mm 

d 

m 

reset  (SEG) ; reset_sel f (SF) 
sv.state-CLOSED 

|  VAL  ID 

YES 

YES 

d 

d 

d 

d 

reset_self  (RA) ; sv . state*CLOSED 

STATE  =  F I N_WA I T2  (con1 t) 
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STATE  -  LAST  ACK 


Event:  Abort  (  LCN  ) 

Actions:  reset_se 1 f (UA) ;  sv . state“CLOSED 

Event:  Send  () 

or  CloseO 
or  Al  locate  () 

Actions:  error ("Connect i on  closing.") 


Event:  Active  Open  () 

or  Active  Open  with  data() 
or  Full  Passive  Open  () 
or  Unspecified  Passive  Open  () 

Actions:  error  ("Connect i on  already  exists.") 


Event:  Retansm i ss i on  Timeout 

* 

Actions:  retransmit 


Event:  ULP  Timeout 

Actions:  reset  (CURRENT) ;  reset_se I f  (UT) ;  sv . state-CLOSED 


I 

i 
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STATE  -  LAST  ACK  (con't) 


Legend 


d  =  "don't  care"  condition 

Event:  NET_DEL 1 VER  (SOURCE  ADDRESS,  DESTINATION  ADDRESS,  PROTOCOL, 

TOS [precedence,  reliability,  delay,  throughput], 
OPT  I ONS [secur i ty] ,  LENGTH,  DATA) 


Act i ons : 


Seq# 

status 

7 

RST 

on? 

Sec 

prec 

match? 

SYN 
i  n 

wndow 

ACK 

status 

test2? 

FIN 

ACK'd 

7 

| INVAL 

NO 

d 

d 

d 

d 

send_ack  (sv. recv_next) 

| INVAL 

YES 

d 

d 

d 

d 

—  no  action 

VALID 

NO 

NO 

d 

d 

d 

reset  (S EG) ; reset_sel f (SP) 
sv.state=CLOSED 

|  VAL  1  D 

NO 

YES 

NO 

NONE 

d 

--  no  action 

|  VAL  1  D 

NO 

YES 

NO 

INVAL 

d 

send_ack  (sv.recv_next) 

)  VAL  1  D 

NO 

YES 

NO 

VALID 

NO 

—  no  action 

|  VAL  ID 

NO 

YES 

NO 

VALID 

YES 

reset_self (UC) ;sv.state«CLOSED 

|  VAL  ID 

YES 

YES 

YES 

mm 

d 

reset  (SEG) ; reset_sel f (SF) 
sv.state**CLOSED 

|  VAL  1  D 

YES 

d 

d 

d 

d 

reset_sel f (RA)  {sv-statc'CLOSED 
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STATE  =  TIME  WAIT 


Event:  Abort (  LCN  ) 

Actions:  reset  self(UA);  sv.state=CLOSED 


Event:  Send  () 

or  CloseO 
or  A1  locate  () 

Actions:  error  ("Connection  closing.") 


Event:  Active  Open  () 

or  Active  Open  with  data() 
or  Full  Passive  Open  () 
or  Unspecified  Passive  Open  () 

Actions:  error  ("Connect i on  already  exists.") 


Event:  Time  Wait  Timeout 

Actions:  reset  self(UC);  sv.state=CLOSED 
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STATE  *  Tlrt£_WAIT  (con't)  Legend 

d  *  "don't  care"  condition 

Event:  NET_DEL I VER  (SOURCE  ADDRESS,  DESTINATION  ADDRESS,  PROTOCOL, 

TOS [precedence,  reliability,  delay,  throughput], 
OPT  I ONS [secur i ty]  ,  LENGTH,  DATA) 

Actions: 


Seq# 

status 

? 

=S«S3I 

RST 

on? 

:s=3szz: 

Sec 

prec 

match? 

SYN  ACK 

in  status 

wndow  test2? 

szsb: 

FIN 

on? 

1 1 NVAL  j 

NO 

d 

d  |  d  j 

d 

| send_ack  (sv. recv_next) 

|  1  NVAL  | 

YES 

d 

1  d  1 

d 

no  action 

VALID 

NO 

NO 

d 

d 

d 

reset  (SEG) ; reset_sel f (SP) 

sv.state“CLOSED 

|  VAL  1  D  | 

NO 

YES 

NO 

|  NONE  | 

d 

|—  no  action 

| VAL 1 0  | 

NO 

YES 

NO 

(INVAL  j 

d 

|send_ack  (sv . recv_next) 

| VAL ID  | 

NO 

YES 

NO 

[VALID  j 

NO 

) —  no  action 

VALID 

NO 

YES 

NO 

VALID 

YES | send_ack  (sv.recv_next) 

|  res  tar t_t ime_wa i t 

VALID 

NO 

YES 

YES 

d 

d 

reset  (SEG) ; reset_sel f (SF) 

sv.state=CLOSED 

(VALID  | 

YES 

d 

* 

1  d  t 

d 

| reset_sel f  (RA) ; sv.state=CLOSED 
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0.3-6. 2  Decision  Func t i ons  The  following  functions  examine  information  con¬ 
tained  in  interface  parameters,  interface  data,  and  the  state  vector  to  make 
decisions.  These  decisions  can  be  thought  of  as  further  refinements  of  the 
event  and/or  state.  The  return  values  of  the  functions  represent  decisions 
made. 

6. 3- 6. 2.1  ACK  on?  The  ACK_on  function  determines  whether  the  acknowledgement 
field  of  the  incoming  segment  is  in  use. 

The  data  effects  of  this  function  are: 

-  Data  examined  only:  f rom_NET . seg . ack_f 1 ag 

-  Return  values: 


NO 

--  indicates 
should  not 

the 

be 

ACK  flag 
exam i ned 

is  false  and 

the 

ACK 

number 

YES 

--  indicates 
is  in  use 

that 

the  ACK 

flag  is  true 

and 

the 

ACK  number 

if  (f rom_NET. seg . ack_f 1 ag  =  TRUE  ) 
then  return  (YES) 
else  return  (NO) ; 
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I 

I 

I 

I 

I 


6. 3. 6. 2. 2  ACK  status  test  1 ?  The  ACK_status_testl  function  compares  the  ACK 
number  of  the  incoming  segment  with  the  current  send  variables  to  determine 
whether  the  ACK  is  valid.  This  function  is  intended  for  use  during  connection 
establishment  when  "old  duplicate"  ACKs  cannot  occur. 

The  data  effects  of  this  function  are: 

-  Data  examined  only: 

f rom_NET.seg .ack_num  sv.send_next 

f rom_NET . seg . ack_f lag  sv . send_una 

-  Return  values: 

NONE  --  no  ACK  appears  in  the  incoming  segment 
INVALID  --  the  incoming  segment  carries  an  ACK  which  is 
outside  the  send  window 

VALID  --  the  incoming  segment  carries  an  ACK  inside  the  send 
window  which  should  be  used  for  I'pdate 

--During  connection  establishment,  an  ACK  is  valid  if 
--it  falls  inside  the  send  window  because  old  ACKs  do  not 
--exist  for  this  connection  incarnation. 


--Check  for  presence  of  ack  flag. 

if  (f rom_NET.seg.ack_f lag  =  FALSE  ) 
then  return  (NONE) 

else  --Validate  ACK  against  current  send  window 

if  (f rom_NET . seg . ack_num  =<  sv.send_una) 

or  (f rom_NET . seg .ack_num  >  sv . send_next) 

then  return  (INVALID  )  --present  but  unacceptable 

else  return  (VALID);  --present  and  inside  send  window 
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6. 3. 6. 2. 3  ACK  status  test2?  The  ACK_status_test2  function  examines  the  ACK 
number  of  the  incoming  segment  against  the  current  send  variables  to  determine 
whether  the  ACK  is  valid.  This  function  is  intended  for  use  after  connection 
establishment  when  old  duplicate  ACKs  can  legally  occur. 

The  data  effects  of  this  function  are: 

-  Data  examined  only: 

f rom_NET. seg .ack_f lag  sv . send_next 

f  rom_NET . seg . ack_num 

-  Return  values: 

NONE  --  no  ACK  appears  in  the  incoming  segment 
INVALID  --  the  incoming  segment  carries  an  ACK  for 
something  which  has  not  yet  been  sent. 

VALID  --  the  incoming  segment  carries  an  ACK  which  either 

falls  in  the  window  (and  should  be  used  for  update) 
or  duplicates  a  previous  ACK. 

--After  a  connec.,on  is  established,  an  ACK  is  valid  if 
--it  ACKs  something  -ent  on  this  connection  incarnation. 

--Check  for  presence  of  ack  flag. 

if  (f rom_NET. seg .ack_f lag  *  FALSE  ) 
then  return  (NONE) 

else  --Validate  ACK  against  current  send  window 
if  (f rom_NET.seg.ack_num  >  sv . send_next) 
then  return  (INVALID  )  --present  but  unacceptable 
else  return  (VALID);  — present  and  okay 
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6.3.6.2.U  checksum  check?  The  checksum_check  function  computes  the  checksum 
of  an  incoming  segment  and  compares  it  against  the  checksum  field  in  the 
header  of  the  incoming  segment. 

The  data  effects  of  this  function  are: 

-  Data  examined  only: 

all  fields  of  from_N£T.seg 
f rom_NET . source_addr 
f rom_NET .dest i nat i on_addr 

-  Return  values: 


NO 

--  indicates 

that 

the 

computed 

checksum  does  not 

match  the 

va  1  ue 

i  n 

f  r  om_N  E  T . 

seg .  checksum 

YES 

--  indicates 

that 

the 

computed 

checksum 

matches  the  va  1 

ue 

in  from_NET. seg . checksum 

--The  checksum  algorithm  is  the  16  bit  one's  complement  of  the 
--one's  complement  sum  of  all  16  bit  words  in  the  segment 
— header  and  segment  text.  If  a  segment  contains  an  odd  number 
— of  octets,  the  last  octet  is  padded  on  the  right  with  zeros 
--to  form  a  1 6 -b i t  word  for  checksum  purposes. 

— While  computing  the  checksum,  the  checksum  field  itself  is  replaced 
— wi th  zeros . 

--The  checksum  includes  a  96-bit  pseudo  header  prefixed  to  the 
--actual  TCP  header.  The  pseudo  header  contains  the 
--source  address,  the  destination  address,  the  protocol  identifier 
--and  the  length  of  the  TCP  segment  (not  counting  the  pseudo  header) 
--as  passed  by  the  NET_DELIVER  service  primitive. 


+ — 

1 

Source  Address 

- + 

1 

1 

Destination  Address 

1 

+ — 

- + 

|  zero  | Protoco 1 |  Segment  length  | 
+ - + 


from_NET.F’  otocol 
f rom_NET. length 


— The  actual  computation  is  implementation  dependent. 


I 
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6. 3*6. 2. 5  F 1 N  ACK ' d?  The  F I N _ ACK 1 d  function  examines  the  acknowledgement 

field  of  the  incoming  segment  to  determine  whether  this  segment  ACKs  a  previ¬ 
ously  sent  FIN. 

The  data  effects  of  this  function  are: 

-  Data  examined  only: 

f rom_N£T . seg .ack_f lag  sv . send_f inflag 

f rom_N£T . seg . ack_num  sv . send_nex t 

-  Return  values: 

NO  --  the  incoming  segment  does  not  ACK  the  FIN 

YES  --  the  incoming  segment'does  carry  an  ACK  of  the 
previously  sent  FIN 

--The  sv.send_f inf  lag  indicates  that  the  ULP  has 

--issued  a  CLOSE.  The  FIN's  sequence  number  is  one  less  than 

— sv . send_next . 

if  (sv.send_f inf  lag  *  TRUE  ) 
then 

if  (from_NET.seg.ack_f lag  =  TRUE)  and 

f rom_NET.seg.ack_num  =  sv.send_next  ) 
then  return  (YES) 
else  return  (NO) 


6. 3. 6. 2. 6  F I N  on?  The  FIN_on  function  determines  whether  the  incoming  seg¬ 
ment  carries  a  FIN  indicating  the  remote  side  has  no  more  data  to  send. 

The  data  effects  of  this  function  are: 

-  Data  examined  only:  f rom_NET . seg . f i n_f 1 ag 

-  Return  values: 

NO  —  the  segment  does  not  contain  a  FIN 

YES  --  the  segment  does  carry  a  FIN 

— The  segment  header  field  seg.fin_flag  indicates  the 
— presence  or  absence  of  a  FIN. 

if  (f rom_NET. seg . f i n_f 1 ag  «  FALSE) 
then  return  (NO) 
el se  return  (YES) ; 


r 


I 

1 

1 
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6. 3. 6. 2. 7  F I N  seen?  The  FIN_seen  function  examines  both  the  incoming  segment 
and  the  sv.recv  variables  for  the  previous  or  current  presence  of  a  FIN  from 
the  remote  TCP.  This  function  is  used  in  the  established  state  because  a  FIN 
may  have  been  recorded  during  connection  opening. 

The  data  effects  of  this  function  are: 

-  Data  examined  only: 

from_N£T.seg.f i n _ f lag  sv.recv_f i nf lag 

-  Return  values: 

NO  --  No  FIN  has  been  received  from  the  remote  TCP  in  this 
or  previous  segments. 

YES  --  A  FIN  has  been  received,  either  in  the  incoming  segment 
or  a  previous  segment. 

--A  FIN  received  during  connection  opening  is  saved  in 

— sv . recv_f i nf 1 ag .  A  FIN  is  present  in  an 

-  incoming  segment  if  f rom_NET . seg . f i n_f I ag  is  set  true. 

if  ((  sv.recv  finflag  =  TRUE  )  or 

(from_NET.seg.f i n_f lag  -  TRUE  )) 
then  return  (YES) 
el se  return  (NO) ; 


6. 3. 6.2. 8  open  mode?  The  open_mode  function  determines  what  kind  of  open 
service  request  the  local  ULP  issued. 

The  data  effects  of  this  function  are: 

-  Data  examined  only:  sv.open_mode 

-  Return  values: 

ACTIVE  --  the  ULP  requested  an  Active  Open  with  or  without 
data  for  this  connection. 

PASSIVE  —  the  ULP  request  a  Full  Passive  Open  or  an 

Unspecified  Passive  Open  for  this  connection. 

--The  type  of  open  request  is  recorded  in  sv.open_mode. 

if  (sv.open_mode  ■  PASSIVE) 
then  return  (PASSIVE) 
else  return  (ACTIVE) ; 


l 
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6. 3. 6. 2. 9  sv  prec  vs  seq  prec?  The  sv_prec_vs_seg_prec  function  compares  the 
precedence  recorded  in  the  state  vector  against  the  precedence  level  of  the 
incoming  segment. 

The  data  effects  of  this  function  are: 

-  Data  examined  only: 

sv .or i g i na 1 _prec  f  rom_NET . type_of_serv ice. precedence 

-  Return  values: 

LESS  -  precedence  in  sv  <  segment  precedence 
EQUAL  -  precedence  i n  sv  *  segment  precedence 
GREATER  -  precedence  i n  sv  >  segment  precedence 

if  (sv.or ig i nal_prec  <  from_NET. precedence  ) 
then  return  (LESS) 

else  if  (sv.or i g i na l_prec  =  from_NET. precedence  ) 
then  return  (EQUAL) 
else  return  (GREATER); 


6.3-6.2.10  resources  suffic  open?  The  resources_suf f i c_open  function  exam¬ 
ines  the  internal  resources  available  in  this  TCP  entity  to  determine  whether 
another  connection  can  be  supported. 

The  data  effects  of  this  function  are: 

-  Data  examined  only:  --implementation  dependent 

-  Return  values: 

NO  --  indicates  that  another  connection  cannot  be  supported 
at  this  time. 

YES  --  indicates  that  internal  resources  are  sufficient 
to  support  another  connection 

--This  function  is  based  on  the  assumption  that  a  TCP  entity 
--has  finite  resources  made  up  of  table  space,  storage  capacity, 

--and  other  implementation  dependent  areas.  Although  the  amount 
--of  these  resources  may  either  be  fixed  at  system  configuration 
--or  vary  dynamically  according  to  system  usage,  more  connections 
--may  be  requested  than  can  be  supported  by  the  entity. 

if  (  enough  resources  are  available  for  another  connection  ) 
then  return  (YES) 
else  return  (NO) ; 
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6.3.6.2.11  resources  suf f i c  send?  The  resources_suf f i c_send  function  exam¬ 
ines  the  resources  of  this  TCP  connection  to  determine  if  more  data  can  be 
accepted  from  the  UIP  for  transfer. 

The  data  effects  of  this  function  are: 

-  Data  examined  only:  --implementation  dependent 

-  Return  values: 

NO  —  indicates  that  data  cannot  be  accepted  from 
the  ULP  at  this  time. 

YES  --  indicates  that  internal  resources  are  sufficient 
to  accept  and  transfer  more  ULP  data  1 

--This  function  is  based  on  the  assumption  that  a  TCP 
— connection  has  finite  resources.  Although  the  amount  of 
— these  resources  may  be  fixed  at  connection  establishment, 

--or  vary  over  connection  lifetime,  at’ some  point  a  sending 
— ULP  might  exceed  the  TCP  entity's  capacity. 

if  (  enough  resources  are  available  to  handle  this  SEND  ) 
then  return  (YES) 
else  return  (NO) ; 

6.3-6.2.12  RST  on?  The  RST_on  function  examines  the  reset  flag  of  the  incom¬ 
ing  segment's  header  to  determine  the  presence  of  a  RST. 

The  data  effects  of  this  function  are: 

-  Data  examined  only:  f rom_NET . seg . r st_f 1 ag 

-  Return  values: 

NO  --  the  incoming  segment  does  not  contain  a  RESET 
YES  --  the  incoming  segment  does  carry  a  RESET 

if  (f rom_NET.seg.rst_f lag  ■  FALSE) 
then  return  (NO) 
else  return  (YES); 
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6.3.6.2.13  sec  match?  The  secjnatch  function  compares  the  security  parame¬ 
ters  (including  security  level,  compartment,  transmission  control  code,  and 
handling  restrictions)  defined  in  the  state  vector  against  those  accompanying 
the  incoming  segment. 

The  data  effects  of  this  function  are: 

-  Oata  examined  only: 

f  rom_NET  .options [security]  sv.sec 

-  Return  values: 

NO  --  The  values  in  the  state  vector  do  not  match  those 
of  the  incoming  segment. 

YES  --  The  security  information  exactly  matches  that  in 
the  state  vector. 

--The  security  information  is  not  carried  in  the  segment  header 
--but  is  passed  by  the  network  protocol  entity  In  the 
--NET_0El I VER  option  parameter. 

if  (f rom_N£T. opt  ions [secur i ty]  =  sv.sec) 
then  return  (YES) 
e I se  return  (NO) ; 
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6.3.6.2.H  sec  prec  a  1 1  owed?  The  sec_prec_al lowed  function  examines  the 
security  and  precedence  information  requested  by  a  ULP  in  a  connection  open 
request  and  based  on  the  implementation  environment  (i.e.  secure  host,  unclas¬ 
sified  system,  etc.)  determines  whether  this  TCP  entity  can  support  them. 

The  data  effects  of  this  function  are: 

-  Data  examined  only: 

from_ULP. precedence  f rom_ULP .security 

-  Return  values: 

NO  —  This  TCP  entity  cannot  support  the  requested  security 
and  precedence. 

YES  --  The  security  and  precedence  requested  can  be  supported. 

--This  decision  is  implementation  dependent. 

6.3.6.2.15  sec  prec  match?  The  sec_prec_match  function  compares  the  pre¬ 
cedence  level  and  security  information  (including  security  level,  compartment, 
transmission  control  code,  and  handling  restrictions)  defined  in  the  state 
vector  against  those  of  the  incoming  segment. 

The  data  effects  of  this  function  are: 

-  Data  examined  only: 

f  rom_NET . type_of _serv i ce . precedence  sv . sec 

f rom_NET.options[secur i ty]  sv.actual_prec 

-  Return  values: 

NO  —  The  security  and  precedence  of  the  segment  do 
not  match  those  of  the  state  vector. 

YES  --  The  security  and  precedence  DO  match. 

if  {(sv.sec  -  f rom_NET. options [secur i ty])  and 

(sv.actual_prec  **  from_NET. type_of_servi ce .precedence) ) 

then  return  (YES) 
else  return  (NO)  ; 
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6. 3-6. 2. 16  seg#  status?  The  seq#_status  function  compares  the  sequence 
number  of  the  incoming  segment  against  the  current  recv  variables  in  the  state 
vector  to  determine  whether  the  segment  contains  data  in  the  recv  window. 

The  data  effects  of  this  function  are: 

-  Data  examined  only:  f rom_NET . seg . seq_num  sv.recv_wndw 

sv.recv  next 


Return  values: 

VALID  --  This  segment  does  not  contain  data  within  the  recv  window. 
INVALID  --  This  segment  DOES  contain  data  in  the  recv  window. 

--Due  to  zero  length  recv’window  and  zero  length  segments, 

--this  decision  function  must  examine  four  cases. 

--These  cases  are  expressed  in  the  following  conditional  statements. 

if  (f rom_NET . 1 ength  =  0) 
then  if  (sv. recv_wndw  =  0) 
then 

--When  the  segment  contains  no  data,  and  the  receive 
— window  is  closed,  the  segment  sequence  number 
--must  equal  the  next  expected  to  be  acceptable, 
if  (f rom_net . seg . seq_num  =  sv . recv_next) 
then  return  (YES) 
else  return  (NO) 

e  1  se 

--When  the  segment  contains  no  data  and  the  receive 
--window  is  open,  the  segment  sequence  number  must 
--fall  within  the  receive  window, 
if  (sv. recv_next  ■<  f rom_NET . seg . seq_num)  and 

(f rom_NET . seg . seq_num  <  sv.recv_next+sv.recv_wndw) ) 
then  return  (YES) 
else  return  (NO) 

else  if  (sv.recv_wndw  •«  0) 
then 

— When  the  segment  carries  data  and  the  receive 
— window  is  closed,  although  no  data  can  be 
--accepted,  the  control  information  is  acceptable 
--if  the  segment  sequence  number  exactly  matches 
--the  next  expected. 

if  (f rom_net . seg . seq_num  ■  sv. recv_next) 
then  return  (YES) 
else  return  (NO) 

else 

--When  the  segment  carries  data  and  the  receive  window 
—  is  open,  the  segment  is  acceptable  if  any  data 
— fails  within  the  receive  window, 
if 

--Does  the  front  of  the  data  lie  within  the  window? 

( ( (sv. recv_next  *<  from_NET.seg.seq_num) 
and  (from_NET.seg.seq_num  <  sv . recv_next+sv . recv_wndw) ) 
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or 

— Does  the  back  of  the  data  lie  within  the  window? 

( (sv . recv_next  =<  from_NET.seg.seq_num+from_NET. length) 
and  (from_NET. 1 ength+f rom_NET . seg . seq_num  < 

sv.recv_next+sv.recv_wndw) ) 
or 

--Does  the  middle  of  the  data  lie  within  the  window? 

( (sv.recv_next  >  f rom_net . seg . seq_num) 
and  (  sv.recv_next+sv.recv_wndw  < 

(from_N£T. I ength+f rom_NET . seg . seq_num) ) ) ) 
then  return  (YES) 
else  return  (NO) ; 


6.3.6.2.17  SYN  on?  The  SYN_on  function  examines  the  SYN  flag  of  the  incoming 
segment.  The  data  effects  of  this  function  are: 


-  Data  examined  only:  from_NET.seg.syn_f lag 

-  Return  values: 

NO  —  No  SYN  is  present  in  the  incoming  segment. 
YES  —  A  SYN  is  present  in  the  segment. 

if  (f rom_NET.seg.syn_f lag  ■  TRUE) 
then  return  (YES) 
e I se  return  (NO) ; 
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6.3*8.2.18  SYN  i n  wndow?  The  SYN_in_wndow  function  determines  whether  an 
incoming  segment  contains  a  SYN,  and  if  so,  whether  its  sequence  number  lies 
in  the  recv  window. 

The  data  effects  of  this  function  are: 

-  Oata  examined  only: 

f rom_NET . seg . syn_f 1 ag  sv . r ecv_next 

f  rom_NET. seg . seq_num  sv . r ecv_wndw 

-  Return  values: 

NO  --  No  SYN  is  present,  or  a  SYN  is  present  but  it  does 
not  fall  in  the  recv  window. 

YES  --  A  SYN  is  present  and  falls  in  the  recv  window. 

— After  a  connection  is  established,  no  segments  should  contain 
--SYNs.  However,  certain  situations  may  produce  a  SYN. 

--Shortly  after  a  connection  opens,  a  duplicate  of  the  original 
— SYN  may  arrive.  It  will  not  lie  in  the  recv  window,  having 
— already  been  accepted.  Or,  during  a  connection  of  long 
— duration,  very  very  rare  error  conditions  may  produce  a  SYN  within 
--the  recv  window.  This  situation  must  be  detected. 

if  ( (f rom_NET. seg .syn_f 1 ag  =  TRUE  )  and 

(from_NET.seg.seq_num  >=  sv . recv_next)  and 
(f rom_N?T. seg . sea_num  <  sv.recv_next  +  sv . recv_wndw) ) 

then  return  (YES) 
else  return  (NO) ; 


6.3*6.2.19  zero  recv  wndow?  The  zero_recv_wndow  function  examines  the 
recv_var i ab I es  to  determine  whether  the  recv  window  is  zero,  preventing  the 
acceptance  of  any  data  from  the  remote  TCP. 

The  data  effects  of  this  function  are: 

-  Data  examined  only:  sv.recv_wndw 

-  Return  values: 

NO  --  The  recv  window  is  not  zero.  Data  can  be  accepted. 

YES  --  The  recv  window  IS  zero.  No  data  can  be  accepted. 

if  (sv.recv_wndw  *  0) 
then  return  (YES) 
el se  return  (NO) ; 
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6. 3-6.3  Action  Procedures  The  following  action  procedures  represent  the  set 
of  actions  performed  by  a  TCP  entity  state  machine.  They  are  called  by  the 
state  and  event  correspondence  defined  in  Section  6.3.6.  These  procedures 
have  been  organized  and  designed  for  clarity  and  are  provided  as  guidelines. 
Although  implementors  can  reorganize  for  better  performance,  the  data  effects 
of  the  resulting  implementations  must  not  differ  from  those  specified  below. 

Certain  aspects  of  the  actions  described  in  the  following  procedures  are  sub¬ 
ject  to  design  choices.  Specifically,  the  selection  of  strategies  for  han¬ 
dling  retransmissions,  sending  acknowledgements,  segmenting  data,  accepting 
data  from  the  remote  TCP,  and  delivering  data  to  the  ULP  are  governed  by 
implementation  dependent  criteria.  These  strategies  are  encapsulated  in  "pol¬ 
icy"  procedures  such  as  accept_po 1 i cy .  A  policy  procedure  discusses  the 
available  approaches  and  returns  information  to  an  action  procedure  indicating 
appropriate  processing.  The  policy  procedures  defined  in  the  following  sec¬ 
tion  are:  accept_po I i cy ,  ack_policy,  de 1 i ver_po 1 i cy ,  retransmi t_pol i cy ,  and 
send_po! icy. 

This  specification  is  intended  to  be  as  detailed  and  accurate  as  possible 
without  implying  a  particular  implementation  approach  or  environment.  How¬ 
ever,  a  difficulty  lies  in  the  manipulation  of  internal  data  storage  areas 
which  is,  by  nature,  implementation  dependent.  Thus,  a  set  of  data  management 
routines  are  defined  to  manipulate  the  queues  for  send  and  receive  data  while 
specific  data  structures  (such  as  arrays,  linked  lists,  or  circular  buffers) 
remain  undefined.  The  state  vector  can  record  the  send  and  receive  variables 
in  terms  of  sequence  numbers  because  the  data  routines  correlate  sequence 
numbers  to  the  physical  position  of  data  within  the  data  structures.  The  data 
management  routines  defined  in  the  following  section  are:  dm_add_to_recv , 
dm_add_to_send,  dm_copy_f rom_send,  dm_remove_f rom_send,  and 
dm_r  emove_f  r  om_r  ecv . 

The  actions  procedures  invoke  the  execution  environment  primitives,  defined  in 
Section  7.  to  pass  messages  between  protocol  levels  (TRANSFER),  to  read 
current  time  (CURRENT_TI ME) ,  and  to  set  and  cancel  timers  (SET_TIMER, 
CANCEL  TIMER) . 
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6. 3-8. 3-1  accept  The  accept  action  procedure  accepts  data  from  the  incoming 
segment  and  places  it  in  the  receive  queue.  The  amount  of  data  accepted  is 
governed  by  the  implementation  dependent  acceptance  policy.  An  ACK  is  gen¬ 
erated  for  the  accepted  data  according  to  the  ack  policy  which  is  implementa¬ 
tion  dependent.  Also,  some  data  may  be  delivered  according  implementation 
dependent  delivery  policies. 

The  data  effects  of  this  procedure  are: 

-  Data  examined: 

all  fields  in  from_NET  sv . recv_a I  1 oc 

-  Data  mod i f i ed : 

all  fields  of  to_NET 
sv.recv_next 
sv. recv_urg 

-  Local  variables:  start_seq  amount  offset 

--The  accept_po 1 i cy  procedure  returns  how  much 
--data  is  to  be  accepted,  its  beginning  sequence  number, 

— and  its  location  within  the  incoming  segment. 

accept_pol i cy (  amount,  start_seq,  offset  ); 

if  (amount  >  0) 
then 

dm_aad_to_recv  (  start_seq,  amount,  offset  ) ; 

--Update  the  recv_next  sequence  number  if  necessary, 
if  (sv.recv_next  «  start_seq) 
then  sv.recv_next  :*  start_seq  +  amount; 

--Record  PUSH  and  URGENT  information, 
if  ( (f rom_NET.seg.push_f 1 ag  »  TRUE)  and 
(sv. recv_push  <  start_seq  +  amount)) 
then  sv.recv_push  :=  start_seq  +  amount; 

if  ( (f rom_NET. seg .urg_f 1 ag  *  TRUE)  and 

(sv.recv_urg  <  f rom_N£T . seg . seq_num  +  f rom_NET . seg .urgptr) ) 
then  sv.recv_urg  :®  f rom_NET . seg . seq_num  +  f rom_NET . seg . urgptr ; 

--Refer  to  ack_policy  to  determine  whether  an  ACK  should  be  generated 
--at  this  point. 

to_ack  :■  ack_pol  i  cy  ()  ; 
i f  (to_ack  »  TRUE) 
then  send_ack (  sv.recv_next  ); 

—  If  the  allocation  allows,  deliver  data  to  the  ULP. 

if  (sv . recv_a 1 1 oc  >  0) 
then  de 1 i ver ; 
end; 


sv . recv_wndw 
sv. recv_push 
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6. 3. 6. 3. 2  accept  po 1  icy  As  one  of  the  policy  procedures,  ao.ept_pol i cy 
discusses  the  alternative  strategies  for  accepting  the  data  of  incoming  seg¬ 
ments  and  returns  to  the  calling  procedure  the  number  of  data  octets  to  be 
accepted . 

The  parameters  are: 

1.  starti ng_seq  -  sequence  number  of  the  first  octet  of  data  to  be  accepted 

2.  quantity  -  the  number  of  octets  of  data  to  be  accepted 

3-  segment_data_of f set  -  the  position  of  the  first  data  octet  within  the 
incoming  segment's  text  to  be  accepted. 

A  TCP  implementation  may  use  one  of  several  strategies  to  accept  data  within 
the  receive  window  from  an  incoming  segment. 

1.  Accept  in-order  data  only.  The  acceptance  test  is: 

from_N£T.seg.seq_num  =  sv.recv_next 

That  is,  the  sequence  number  of  the  incoming  segment  must  exactly  equal 
the  next  sequence  number  expected  to  be  received. 

2.  Accept  any  data  within  the  receive  window.  The  acceptance  test  has 
several  parts: 

sv.recv_next  ■=<  f rom_NET . seg . seq_num 

=<  sv.recv_next  +  sv.recv_wndw 

-  or  - 

sv.recv_next  =*<  f rom_NET . seg . seq_num  +  length 

»<  sv.recv_next  +  sv.recv_wndw 

That  is,  any  portion  of  the  text  falling  within  the  receive  window  (i.e. 
in  the  interval  between  the  next  sequence  number  expected  to  be  received 
and  the  last  sequence  number  in  the  window)  is  accepted. 

The  "in-order"  strategy  allows  a  simple  acceptance  test  and  a  straightforward 
scheme  for  data  storage.  However,  the  loss  of  a  single  segment  can  result  in 
the  remote  TCP  retransmitting  every  succeeding  segment.  The  " i n-the-wi ndow" 
strategy  requires  a  more  involved  acceptance  test  and  a  sophisticated  data 
storage  scheme  to  keep  track  of  data  accepted  out  of  order.  Also,  as  each 
segment  is  accepted,  the  data  storage  must  be  checked  so  that  a  contiguous 
interval  of  out-of-order  data  can  be  recognized.  This  strategy  allows  the 
remote  TCP  to  retransmit  only  lost  segments. 
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6. 3. 6. 3-3  ack  pol icy  As  one  of  the  policy  procedures,  ack_policy  discusses 
the  alternative  strategies  for  acknowledging  data  accepted  from  incoming  seg¬ 
ments  and  returns  to  the  calling  action  procedure  a  boolean  value  indicating 
whether  an  acknowledgement  should  be  sent. 

A  TCP  implementation  may  apply  one  of  two  acknowledgement  timing  schemes. 

a.  When  data  is  accepted  from  remote  TCP,  immediately  generate  an  empty  seg¬ 
ment  containing  current  acknowledgement  information  and  return  it  to  the 
remote  TCP. 

b.  When  data  is  accepted  from  remote  TCP,  record  the  need  to  acknowledge 
data  in  the  state  vector,  but  wait  for  an  outbound  segment  with  data  on 
which  to  piggyback  the  ACK.  However  to  avoid  a  long  delay,  set  an  "ack 
timer"  to  limit  the  delay  to  a  reasonable  interval.  Thus,  if  no  outbound 
segment  with  data  is  produced  within  the  chosen  ack  timeout  interval,  the 
timer  expires  and  an  empty  ACK  segment  is  generated  and  sent  to  the 
remote  TCP.  If  a  data  segment  is  produced  before  the  timer  expires,  the 
timer  is  cancelled  and  the  need  to  acknowledge  record  is  erased  from  the 
state  vector.  (Note  that  no  "ack  timeout"  event  appears  in  this  specifi¬ 
cation.  This  event  and  the  resulting  call  to  the  send_ack  action  pro¬ 
cedure  should  be  added  if  the  this  approach  is  taken.) 

The  trade-off  between  the  two  approaches  is"  processing  time  versus  control 
overhead.  The  "automatic"  ack  approach  is  simple,  but  results  in  extra  seg¬ 
ment  generation.  The  "timed"  ack  approach  requires  more  processing  but  will 
reduce  the  number  of  segments  generated  on  connections  with  two-way  data 
transfer . 


I 
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6. 3-6. 3-4  check  urq  The  check_urg  action  procedure  examines  the  header  of 
the  incoming  segment  to  determine  whether  new  urgent  information  is  present. 
If  so,  the  urgent  pointer  is  recorded  in  the  recv  variables. 

The  data  effects  of  this  procedure  are: 

Data  examined: 

f rom_NET . seg .urg_f 1 ag  f rom_NET. seg .data_of f set 

from_N£T.seg.urgptr  from_NET. length 

f rom_NET  .seg .  seq_nu..; 

-  Data  modified:  sv.recv_urg 

beg  i  n 

--Check  urgent  flag  and  urgent  pointer, 
if  (f rom_N£T. seg .urg_f lag  ■  TRUE) 

then  — Check  to  see  if  a  new  urgent  pointer  is  present. 

if  (sv.recv_urg  <  f rom_N£T.seg . seq_num  +  from_NET.seg.urgptr) 
then 

if  (sv.recv_urg  <  sv.recv_save) 

then  — If  the  ULP  is  not  in  "urgent  mode",  it  must  be 
—  informed  of  the  presence  of  urgent  information. 

—  implementation  dependent  action 
sv.recv_urg  :*=  f rom_NET. seg . seq_num  +  from_NET.seg.urgptr; 
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6. 3. 6. 3*5  compute  checksum  The  compute_checksum  procedure  computes  the 
checksum  of  an  outbound  segment  and  places  the  value  in  the  header's  checksum 
field. 

The  data  effects  of  this  function  are: 

-  Data  examined: 

all  fields  of  to_NET.seg 
to_NET . source_addr 
to_N£T .des t i nat i on_addr 

-  Data  modified:  to_NET.seg. checksum 
beg  i  n 

— The  checksum  algorithm  is  the  16  bit  one's  complement  of  the 
--one's  complement  sum  of  all  l£>  bit  words  in  the  segment 
— header  and  segment  text.  If  a  segment  contains  an  odd  number 
--of  octets,  the  last  octet  is  padded  on  the  right  with  zeros 
--to  form  a  16-bit  word  for  checksum  purposes.  While  computing 

-  the  checksum,  the  checksum  field  itself  is  replaced  with  zeros. 

--The  checksum  includes  a  96"bit  pseudo  header  prefixed  to  the 
--actual  TCP  header.  As,  the  diagrams  shows,  the  pseudo  header 
--contains  the  source  address,  the  destination  address,  the 
— protocol  identifier,  and  the  length  of  the  TCP  segment 

--(not  counting  the  pseudo  header). 

.+ - + - + - + 

Source  Address  I 


Destination  Address 

- + 

zero  |Protocol|  Segment  length  | 
- + 

--The  actual  computation  is  implementation  dependent, 
end; 


to_NET. protocol 
to_NET . 1 ength 
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6. 3*6. 3-6  conn  open  The  conn_open  action  procedure  is  called  just  before  a 
connection  enters  the  ESTABLISHED  state.  According  to  the  implementation  pol¬ 
icy,  the  procedure  updates  the  ACK  and  window  information,  delivers  any  wait¬ 
ing  data,  and  acknowledges  any  received  data.  The  ULP  is  notified  of-  the 
newly  opened  connection  with  an  OPEN_SUCCESS  service  response. 

The  data  effects  of  the  procedure  are: 

-  Data  examined:  sv.lcn 

-  Data  modified:  to_ULP . serv i ce_response  to_ULP.lcn 

-  Local  variables:  del i very_amount  need_to_ack 


beg  i  n 

—  Inform  the  ULP. 

to_ULP . servi ce_response  :=  OPEN_SUCCESS ; 
to_ULP.lcn  sv.lcn: 

TRANSFER  to_ULP  to  the  ULP  identified  by  sv.source_port; 

— The  incoming  segment  contained  either  a  SYN  and  an  ACK  of 
--our  SYN,  or  just  an  ACK.  In  either  case,  use  the  new 
— ack  to  update  the  send  variables, 
update: 

— Based  on  imp  1 ementa t i on  dependent  policies,  deliver  any  waiting 
--data  to  the  ULP. 

del i very_amount  :*  del iver_pol icy  () ; 
if  (del i very_amount  >  0)  then  deliver; 

--Based  on  implementation  dependent  acking  policy,  ack  the 
--incoming  segment. 

need_to_ack  :»  ack_pol i cy 0  ; 

if  (need  to  ack  -  TRUE)  then  send  ack; 


end; 
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6. 3. 6. 3. 7  de ) i ver  The  deliver  action  procedure  moves  data  accepted  from  the 
remote  TCP  into  the  to_ULP  structure  for  delivery  to  the  ULP.  The  amount  of 
data  delivered  is  based  on  the  receive  allocation,  the  amount  of  pushed  data, 
and  the  implementation  dependent  delivery  policy. 

The  data  effects  of  this  procedure  are: 

-  Data  examined: 

sv. recv_push 
sv . recv_urg 
sv .  1 cn 

-  Data  modi f i ed: 

sv. recv_save 
sv.recv_al loc 

-  Local  variables:  pushed  de 1 i very_amount  urgent_l ength 
beg  i  n 

--Does  pushed  data  await  delivery? 
if  (sv.recv_push  >  sv.recv_save) 

then  --Pushed  data  waits  so  compute  amount  needing  delivery, 
if  (sv.recv_push  >  sv . recv_next) 
then  pushed  :=  sv.recv_next  -  sv.recv_save 
else  pushed  :=  sv.recv_push  -  sv.recv_save; 

—  Is  there  enough  allocation  for  all  the  pushed  data? 
if  (sv . recv_a 1 1 oc  <  pushed) 
then  del ivery_amount  :=  sv . recv_a I loc 
else  del ivery_amount  :=  pushed; 

else  — No  pushed  data  waits.  Refer  to  the  del iver_pol icy 
— to  determine  how  much  data  should  be  passed  to  the 
--ULP  at  this  point. 

del i very_amount  :=  de 1 i ver_pol i cy  () ; 

— Oeliver  computed  amount  of  data  to  ULP,  including  urgent 
— i nf ormat i on . 

if  (del ivery_amount  >  0) 
then  begin 

— Check  for  "end  of  urgent"  in  data  which  cannot  be  delivered 
—  in  the  same  delivery  unit  with  subsequent  non-urgent  data. 

if  { (sv. recv_urg  >  sv. recv_save)  and 

(sv.recv_urg  <  sv.recv_save  +  del i very_amount) ) 
then  — Deliver  the  urgent  data  alone  first, 
begi  n 

urgent_!ength  :«  sv.recv_urg  -  sv. recv_save; 

dm_remove_from_recv (sv.recv_save,  urgent_l ength) ; 
to_ULP .data_l ength  :■  urgent_l ength; 

— Note  that  implementation  dependent  delivery  unit 


sv . recv_next 
sv . recv_f i nf 1 ag 
sv.source_port 


all  fields  of  to  ULP 
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--size  restrictions  are  not  handled. 
to_ULP .urgent_f 1 ag  :=  TRUE; 
to_ULP.lcn  :*  sv.lcn; 
to_ULP. servi ce_response  :=  DELIVER; 

TRANSFER  to_ULP  to  the  ULP  named  by  to_ULP . source_por t ; 
sv.recv_save  :=  sv.recv_urg; 

sv.recv_al loc  :*  sv . recv_a 1 1 oc  -  urgent_length; 
de I i very_amount  :«  del i very_amount  -  urgent_l ength ; 
end ; 

--Move  data  without  an  end  of  urgent  into  to_ULP.data 
--and  deliver  to  ULP. 

dm_remove_f rom_recv (sv.recv_save,  de) i very_amount) ; 
to_ULP .data_l ength  :=  de 1 i very_amount ; 

--Note  that  implementation  dependent  delivery  unit 

--size  restrictions  are  not  handled. 

to_ULP.lcn  :*  sv.lcn; 

if  (sv.recv_save  <  sv.recv_urg) 

then  to_ULP.urgent_f lag  :*  TRUE 

else  to_ULP.urgent_f I ag  ; »  FALSE; 

TRANSFER  to_ULP  to  the  ULP  named  by  sv.source_port; 

— Update  recv  variables. 

sv.recv_save  :«  sv.recv_save  +  de I i very_amount ; 
sv.recv_al loc  :«  sv . recv_a 1 1 oc  -  del ivery_amount; 

--If  the  remote  side  has  closed,  and  this  data  clears  the 
--receive  queue,  the  ULP  must  be  notified, 
if  ( (sv. recv_f i nf 1 ag  -  TRUE)  and 
(sv.recv_next  ■  sv . recv_save) ) 

then 

begi  n 

to_ULP.service_response  :*  CLOSING; 
to_ULP. Icn  :«  sv.lcn; 

TRANSFER  to_ULP  to  the  ULP  named  by  sv.source_port; 
end; 

end;  --of  data  del ivery  to  ULP 
end; 
end; 
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6. 3. 6. 3. 8  de 1 i ver  po 1  icy  As  one  of  the  policy  procedures,  del iver_pol icy 
discusses  the  alternative  strategies  for  delivering  data  to  the  ULP.  It 
returns  to  the  calling  procedure  the  nun.ner  of  octets  of  data  to  be  delivered. 

Barring  zero  receive  allocations  and  pushed  data,  the  TCP  specification  allows 
an  implementation  to  deliver  data  to  the  ULP  at  its  own  convenience.  However, 
performance  considerations  should  be  examined.  On  one  hand,  data  available 
for  delivery  should  be  delivered  with  reasonable  promptness;  it  should  not  be 
delayed  indefinitely  while  waiting  for  a  delivery  units  worth  to  arrive.  On 
the  other  hand,  the  data  should  not  be  delivered  an  octet  at  a  time  wasting 
both  internal  TCP  processing  time  and  external  execution  environment 
resources.  A  reasonable  compromise  can  be  achieved  guided  by  system  design 
cr i ter i a . 
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6. 3-6. 3. 9  d  i  spa tch  The  dispatch  action  procedure  accepts  the  data  and  inter¬ 
face  parameters  passed  by  the  ULP  in  a  send  request,  adds  the  data  to  the  send 
queue,  and  adjusts  appropriate  send  variables.  Depending  on  the  send  policy, 
the  procedure  may  segment  and  transmit  some  portion  of  data  to  the  remote  TCP. 
The  data  effects  of  this  procedure  are: 

-  Data  examined: 

f rom_ULP . 1 cn 
f rom_ULP .data 
f rom_ULP .data_l 

-  Data  mod i f i ed : 

sv.send_f ree 
sv .u I p_t i meout 
sv.send_push 
sv.send_urg 

begin 

--Save  the  data  along  with  timestamp,  starting  at  sv.send_free, 

--then  update  the  send  variables. 

add_to_send (sv.send_f ree,  f rom_ULP.data_length,  CURRENT_T 1  ME () ) ; 

sv.send_free  :=  sv.send_free  +  f rom_ULP . 1  eng th ; 

if  (f rom_ULP. push_f 1 ag  =  TRUE) 
then  sv.send_push  :*  sv.send_f ree; 

if  (from_ULP.urgent_f lag  ■  TRUE) 
then  sv.send_urg  :•  sv.send_f ree; 

--Depending  on  implementation,  the  ULP  timeout  timer  may 
— need  to  be  restarted  when  the  interval  is  changed  by  the  ULP. 

if  ( (from_ULP.ulp_timeout  ! ! *■  NULL)  --option  exercised  to  set  timeout 
and  (from_ULP.ulp_timeout  ! !«  sv .u 1 p_t i meout) ) 
then  sv.ulp_timeout  :*  from_ULP.ulp_ti meout; 

— Call  the  send_new_data  procedure  to  determine  if  any 
--newly  received  data  can  be  sent  at  this  time. 

send_new_data; 

end;  --non-zero  send  window  processing 

I 

I 
I 


f rom_ULP . push_f 1 ag 
f rom_ULP . urgent_f 1 ag 
gth  from_ULP.u!p_timeout 


sv.send_next 
sv.send_una 
sv.send  wndw 


end; 
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6.3.6.3-10  dm  add  to  send  As  one  of  the  data  management  routines,  the 
dm_add_to_send  procedure  adds  the  data  provided  by  the  ULP  in  f rom_ULP.data  to 
the  send  storage  area. 

The  calling  sequence  is  : 

dm_add_to_send  (  seq_num.  length,  time  ) 

seq_num  *  the  sequence  number  of  the  first  octet 
being  added  to  the  storage  area 

length  =  the  number  of  octets  to  be  added 

time  *  the  current  time  to  be  associated  with  each 

data  octet  for  later  determination  of  data  age 
for  the  ULP  timeout. 


6.3.6.3.11  dm  add  to  recv  As  one  of  the  data  management  routines,  the 
dm_add_to_recv  procedure  copies  data  from  an  incoming  segment,  found  in 
from_NET.seg.data,  into  the  receive  storage  area.  This  routine  is  called  as 
segments  are  validated  and  portions  of  their  data  are  found  to  be  in  the 
receive  window. 

The  calling  sequence  is: 

dm_add_to_recv (  seq_num,  length,  offset  ) 

seq_num  «  the  sequence  number  of  the  first  octet  to  be  copied. 

length  -  the  number  of  data  octet  to  be  copied. 

offset  ■  the  location  of  first  octet  to  be  taken  from  the 
data  portion  of  the  segment. 

6.3.6.3.12  dm  copy  from  send  As  one  of  the  data  management  routines,  the 
dm_copy_f rom_send  procedure  copies  data  from  the  send  storage  area  into 
to_NET.seg.data.  This  routine  is  used  as  data  is  segmented  and  transmitted 
initially,  and  as  retransmi ss ions  are  required. 

The  calling  sequence  is: 

dm_copy_f rom_send (  seq_num,  length  ) 

seq_num  -  the  sequence  number  of  the  first  data  octet  to  be 
copied  into  to_NET.seg.data 

length  -  the  number  of  octets  to  be  copied 
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6. 3*5. 3*'3  dm  remove  from  recv  As  one  of  the  data  management  routines,  the 
dm_remove_f rom_recv  routine  removes  data  from  the  receive  storage  area  and 
places  it  in  the  to_ULP.data  structure.  This  is  called  as  data  is  delivered 
to  the  ULP. 

The  calling  sequence  is: 

dm_remove_f rom_recv  (  seq_num,  length  ) 

seq_num  «  the  sequence  number  of  the  first  octet  to 
be  removed  and  copied 

length  *  the  number  of  data  octets  to  be  removed  and  copied 


6.3-6,3-l1»  dm  remove  from  send  As  one  of  the  data  management  routines,  the 
dm_remove_f rom_send  procedure  deletes  data  from  the  send  storage  area.  This 
routine  is  called  as  data  is  acknowledged  by  the  remote  TCP  and  removed  from 
the  retransmission  "queue." 

The  calling  sequence  is: 

dm_remove_f rom_send  (  seq_num,  length  ) 

seq_num  ■  the  sequence  number  of  the  first  octet  to  be  removed, 
length  *  the  number  of  data  octets  to  be  removed. 


6.3.6.3.15  error  The  error  procedure  fills  in  the  fields  of  to_ULP  with  the 
local  connection  name,  the  ERROR  service  response,  and  the  error  description 
passed  by  parameter.  This  information  is  passed  to  the  local  ULP. 

-  Data  examined:  sv.lcn  sv. source_port 

-  Data  modified: 

to_ULP . 1 cn  to_ULP . serv i ce_response 

to  ULP. error  desc 


begin 

— Construct  an  error  message  for  the  local  ULP. 

to_ULP.service_response  :-  ERROR; 
to_ULP. Icn  :■  sv. lcn; 
to_ULP.error_desc  :»  parameter; 

TRANSFER  to_ULP  to  the  ULP  named  by  sv. source_port; 


I 

I 

I 


end; 
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6. 3-6. 3. 16  format  net  params  The  f ormat_net_params  procedure  fills  in  the 
parameters  usee  by  the  network  protocol  entity  after  the  calling  procedure  has 
filled  in  the  outgoing  segment  header.  The  size  of  the  segment's  text  portion 
is  passed  by  parameter. 

-  Data  examined: 

to_N£T.seg .data_of fset 
sv .dest i nat i on_addr 
sv.desti nation_port 

-  Data  mod i f i ed: 

to_NET. ident i f i er 
to_NET. protocol 
to_NET.dest i nat i on_add 
to_NET. seg . source_por t 
to_NET.dont_f ragmen t 

beg  i  n 

— Fill  in  the  network  parameters. 

to_NET. seg. sou rce_port  :=  sv.source_port; 

to_NET.seg.desti nation_port  :=  sv .des t i nat i on_por t ; 

to_NET.source_addr  :»  sv . source_addr ; 

to_NET.desti nation_addr  :*■  sv .des t i nat i on_addr ; 

to_NET .protocol  TCP_ID; 

to_NET.type_of_service. precedence  :=  sv.actual_prec; 
to_NET . ty pe_of _serv i ce . re  I i ab i I i ty  :®  NORMAL; 
to_NET . type_of_serv i ce.de 1  ay  :»  NORMAL; 

to_NET. type_of_service. throughput  :=  NORMAL; 
to_NET.  i dent  i  f  i  er  :**  gen_id(); 

t o_N ET. don t_f  ragmen t  :=  FALSE; 

to_NET.time_to_l ive  :«  0NE_MI NUTE_TTL ; 

to_NET . 1 ength  :»  to_NET. seg .data_of fset  +  parameter; 

to_NET.options[securi ty]  :=  sv.sec; 

end; 


sv . source_addr 
sv . source_port 

to_NET . type_of_serv i ce 
to_NET. 1 ength 

r  to_NET . source_addr 

to_NET.de st i nat i on_por t 
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6 . 3  -  6 . 3  •  17  gen  i  d 
calling  procedure 
i s  transmi tted  w i th 


The  gen_id  action  procedure  returns  an  identifier  to  the 
to  be  passed  to  the  network  protocol  entity  when  a  segment 
a  NET  SEND  primitive. 


-  Oata  examined:  --implementation  dependent 

-  Data  modified:  --none 


beg  i  n 

— The  generation  of  the  identifier  is  implementation  dependent. 
--The  network  protocol  entity  uses  the  identifier,  along  with 
— addressing  information,  to  distinguish  between  sending  units 
—  (i .e.  datagrams)  if  fragmentation  and  reassembly  are  required. 
--So,  TCP  must  generate  unique  identifiers  for  each  segment  if 
--the  data  is  to  be  transmitted  without  confusion. 


--Also,  if  a  retransmi tted  segment  is  accompanied  by  the 

-  identifier  used  for  its  original  transmission,  the  network 
— protocol  entity  may  be  able  piece  together  parts  of  the 
--original  and  the  retransmission  to  improve  its  performance. 

— Note  that  if  repackaging  is  performed  during  retransmission, 

--the  original  identifier  cannot  be  used. 

end; 

6.3-6.3.18  gen  i sn  The  gen_isn  procedure  returns  an  initial  sequence  number 
to  the  calling  procedure  for  use  during  the  three-way  handshake  of  connection 
establ i shment . 

-  Data  examined:  --implementation  dependent 

-  Data  modified:  -  none  - 

—  implementation  dependent  action 


6.3.6.3.19  gen  len  The  gen_lcn  procedure  returns  a  local  connection  name,  or 
lcn,  to  the  calling  procedure  to  be  used  as  a  shorthand  identifier  by  TCP  and 
the  local  ULP  in  service  requests  and  responses  pertaining  to  a  connection. 

-  Data  examined:  --implementation  dependent 

-  Data  modified:  -  none  - 


beg  i  n 

--The  generation  of  the  lcn  is  implementation  dependent. 
--A  TCP  entity  usually  supports  many  connections. 

—  If  the  lcn  is  a  pointer  or  table  index,  service  requests 
--can  be  quickly  matched  to  their  state  vector. 


end; 
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6. 3-6. 3-20  gen  syn  The  gen_syn  action  procedure  formats  and  transmits  a  seg¬ 
ment  containing  a  SYN  to  the  remote  TCP.  As  part  of  the  SYN  generation,  an 
initial  sequence  number  is  selected. 

The  procedure  accepts  one  parameter  whose  values  are  ALONE,  WITH_ACK,  and 
WITH_DATA,  indicating  whether  the  segment  will  contain  an  ACK  or  data.  This 
procedure  does  not  handle  generating  a  SYN  carrying  a  FIN  flag  because  the 
specified  service  interface  does  support  a  transaction  primitive  described  in 
Appendix  C.  However,  if  such  primitive  were  created,  this  procedure  would 
have  to  be  modified  to  handle  it. 

The  data  effects  of  this  procedure  are: 

-  Data  examined: 

sv.source_port 
sv .source_addr 
sv .des t i na t i on_por  t 
sv .dest i nat i on_addr 
sv . recv_wndw 
sv.send_urg 

-  Data  modi f i ed: 

sv.send_i sn 
all  f i elds  of  to_NET 

-  Local  variables:  amount 


sv . recv_i sn 
sv . recv_next 
sv.send_next 
sv.send_free 
sv.send_push 


sv. send_next 
sv.send  una 


begin 

— Generate  the  initial  sequence  number  to  be  used  for 
— data  sent  to  the  remote  TCP. 
sv.send_isn  gen_isn(); 

sv.send_next  :=  sv.send_isn  +1;  — SYN  uses  the  first  seq#. 

sv.send_una  :=  sv.send_isn; 

to_NET. seg . seq_num  :»  sv . send_next ; 

— Check  parameter  to  determine  exact  type  of  SYN. 
case  parameter  of 


when  ALONE  *> 

to_NET.seg.ack_f lag  :■  FALSE; 
to_NET.seg.wndw  :■  0; 

to_NET. seg . push_f 1 ag :■  FALSE; 
to_NET . seg . urg_7 I ag  :■  FALSE; 
amount  :»  0; 


when  WITH_ACK  => 

to_NET.seg.ack_f lag  :■  TRUE; 
to_NET. seg .wndw  :*  sv. recv_wndw; 
to_NET.seg.ack_num  :*  sv.recv_isn  +  1; 
to_NET. seg.push_f 1 ag  :*  FALSE; 
to_NET.seg.urg_f 1 ag  :■  FALSE; 
amount  :*  0; 
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when  W I TH_DAT A  => 

to_NET.seg.ack_f lag  :=  FALSE; 
to_NET.seg.wndw  :=  0; 

--The  data  supplied  by  the  ULP  is  in  the  send  queue. 
--However,  the  amount  of  data  to  accompany  the  SYN 
--is  determined  by  the  send_policy. 

amount  :=  send_po  1  i  cy  ()  ; 

i f  (amount  >  0) 

then  dm_copy_f rom_send  (  sv.send_next,  amount  ); 
if  (sv . send_push  =  sv.send_next  +  amount) 
then  to_NET . seg . push_f I ag  :«  TRUE; 
sv.send_next  :=  sv.send_next  +  amount; 
else  to_NET. seg . push_f I ag  :=  FALSE; 
end  case; 

--Add  the  urgent  information  regardless  of  data  length, 
if  (sv.send_urg  >=  to_NET . seg . seq_num) 
then  to_NET.seg .urg_f 1 ag  :=  TRUE; 

to_NET . seg .urgptr  :=  sv.send_urg  -  to_NET . seg . seq_num; 
else  to_NET . seg .urg_f 1 ag  :=  FALSE; 

if  (MAX_SEGMENT_S I ZE  option  used  in  this  implementation) 
then 

to_N£T , seg .opt i ons [l]  :«  2;  --Wax  header  size  option  kind 

to_NET.seg.options[2]  :=  4;  — option  length  =  4  octets 

to_NET.seg.options[3. .4]  MAX_SEGWENT_S I ZE ;  --impl.dep  value 
to_NET.seg.data_of f set  :=  6; 

else 

to_NET.seg.data_of fset  :=  OPT  I ONLESS_HEADER; 

f ormat_net_params (amount)  ; 
compu  t  e_c  h  ec  k  s  um ; 

TRANSFER  to_NET  to  the  network  protocol  entity. 

end; 


I 

I 
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6.3.6.3.21  new  a  1  1  ocat i on  The  new_a 1 1  oca t i on  action  procedure  takes  the  new 
value  provided  by  the  ULP  in  an  allocation  service  request  and  adds  it  to  the 
current  receive  allocation.  Data  waiting  for  this  allocation  is  delivered  to 
the  ULP. 

The  data  effects  of  this  procedure  are: 

-  Data  examined:  f rom_ULP .data_l ength 

-  Data  modified:  sv.recv  alloc 


beg  i  n 

--Add  in  the  new  receive  allocation. 

sv.recv_al loc  :=  sv . recv_a 1 1 oc  +  f rom_ULP .data_l ength ; 

— Depending  on  implementation  dependent  window  management  strategy, 

—  this  new  receive  allocation  may  be  factored  into  a  new 
--value  for  the  receive  window. 

—  If  data  awaits  this  allocation,  deliver  it. 

del i ver ; 


end; 
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6.3*6.3.22  open  The  open  action  procedure  records  the  parameters  from  an 
open  service  request  (either  Active  Open,  Fully  Specified  Passive  Open,  or 
Unspecified  Passive  Open),  assigns  a  local  connection  name,  and  returns  it  to 
the  ULP  in  an  OP EN_ I D  service  response. 

The  data  effects  of  this  procedure  are: 

-  Data  examined: 

f rom_ULP . request_name 

f rom_ULP . source_port  f rom_ULP .precedence 

f rom_ULP.desti nation_port  f rom_ULP.secur i ty 

f rom_ULP .dest i nat i on_addr  f rom_ULP . timeout 

-  Data  mod i f i ed: 

sv.source_port  sv.lcn 

sv.source_addr  sv.or i g i na l_prec 

sv.destination_port  sv.sec 

sv.desti nation_addr  sv.ulp_tiftieout 

to_ULP.servi ce_r esponse  to_ULP .dest i nat i on_addr 
to_ULP . sour ce_por  t  to_ULP . des  t i nat i on_por  t 

to_ULP . source_addr  to_ULP . 1 cn 

beg  i  n 

— Assign  a  local  connection  name  according  to 

—  implementation  dependent  algorithms. 

sv.  Icn  :=  gen_lcn  ()  ; 

— The  security,  precedence,  and  timeout  parameters  are 
— optional.  If  they  are  not  provided  by  the  ULP,  default 
— values  are  assigned.  For  security  and  precedence  defaults 

—  in  nonsecure  environments,  the  lowest  levels  are  generally  used. 

— A  timeout  default  is  more  arbitrary,  but  the  current 
--suggested  value  is  two  minutes. 

if  (f rom_ULP.secur i ty  is  present) 
then  sv.sec  :*■  from  ULP.security 
else  sv.sec  :-  OEFAULT_SECURITY; 

if  (from_ULP. precedence  is  present) 

then  sv .or i g i na l_prec  :*  from_ULP . precedence; 

sv.actual_prec  :»  from_ULP.pt ecedence; 
else  sv.ori ginal_prec  :=  DEFAULT_PRECEDENCE; 
sv.actua!_prec  :-  DEFAULT_PRECEDENCE; 

if  (from_ULP. timeout  is  present) 
then  sv.u!p_timeout  f rom_ULP. t imeout 
else  sv.ulp_timeout  :■*  DEF AULT_T I MEOUT; 


— The  source  port  is  provided  in  all  open  requests.  The  source 
--address  is  the  address  of  this  TCP  entity. 
sv.source_port  :*  f rom_ULP.source_port; 
sv. source  addr  :■  THIS  ADDRESS; 
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— The  remaining  parameters  vary  according  to  open  request  type, 
case  f rom_ULP . reques t_name  of 

when  Unspec i f i ed_Pass i ve_0pen  => 

--This  request  does  not  carry  the  destination 
--socket.  It  remains  unassigned  until  a  matching 
--SYN  from  a  remote  TCP  arrives. 
sv.open_mode  :*  PASSIVE; 

when  Fu I l_Pass i ve_0pen  => 

sv .dest i nat i on_addr  :=  f rom_ULP . des t i na t i on_addr ; 
sv .dest i nat i on_por t  :=  f rom_ULP . des t i na t i on_por t ; 
sv.open_mode  :=  PASSIVE; 

when  Active_Open  => 

sv. dest i nat i on_addr  :=  f rom_ULP . des t i na t i on_addr ; 
sv.destination_port  :*  f rom_ULP .des t i nat i on_por t ; 
sv.open_mode  :=  ACTIVE; 

when  Act  ive_Open_Wi  th_Data  <=> 

sv.destination_addr  :»  f rom_ULP . des t i na t i on_addr ; 
sv. dest i nat ion_port  ;■  from_ULP .dest i nat i on_por t; 
sv.open_mode  :=  ACTIVE; 

— Record  data  accompanying  open  request. 
save_send_data; 

end  case; 

--Return  the  local  connection  name  assigned. 
to_ULP.service_response  ;=  0PEN_1D; 
to_ULP.source_port  :=  sv. source_port; 
to_ULP . source_addr  :=  sv . source_addr ; 
to_ULP .dest i nat ion_addr  :=  sv .dest i nat i on_port; 
to_ULP .dest i nat i on_port  :*  sv. des t i nat i on_addr ; 
to_ULP.lcn  :»  sv.lcn; 

TRANSFER  to_ULP  to  the  UIP  named  by  sv . source_por t ; 


end; 
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6-3*6.3-23  openf a i 1  The  openfai I  action  procedure  informs  the  ULP  that 
attempted  connection  could  not  be  opened.  It  also  clears  the  state  vector 
The  data  effects  of  the  procedure  are: 

-  Data  examined:  sv.lcn  sv,source_port 

-  Data  modified: 

all  state  vector  elements 

to_ULP . 1 cn  to_ULP . serv i ce_response 

— Construct  an  OPEN _ F A  I L  message  for  the  ULP. 

to_ULP.service_response  :=  OPE N_F AIL; 
to_ULP.lcn  :»  sv.lcn; 

TRANSFER  to_ULP  to  the  ULP  named  by  sv.source_port; 

--The  state  vector  is  cleared  without  generating  a  ULP  message. 
reset_self (N0_REP0RT) ; 


the 
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6.3.6.3.24  part  reset  The  part_reset  action  procedure  clears  the  send  and 
recv  variables  without  terminating  the  connection. 

The  data  effects  of  the  procedure  are: 

-  Data  examined:  sv.open_mode 

-  Data  modified:  all  send  and  receive  variables 


beg  i  n 

--The  remote  TCP  address  and  port  are  cleared  if  the  connection 
--open  mode  was  PASSIVE. 

if  (sv . open_mode  =  PASSIVE) 
then 

sv.destination_port  :=  NULL; 
sv.destination_addr  :=  NULL; 


--Clear  all  variables  set  during  the  connection  opening 
--handshake. 

dm_remove_f rom_send (sv . send_una ,  QUEUE_SIZE) ; 
dm_remove_f rom_recv  (sv.recv_f ree,  QUEUE_SIZE) ; 


sv.actual_prec 

=  NULL 

sv . recv_i sn 

-  NULL 

sv.recv_next 

-  NULL 

sv . recv_wndw 

=  NULL 

sv.recv_al ioc 

»  NULL 

sv . recv_push 

*  NULL 

sv.recv_urg 

*  NULL 

sv.recv_save 

-  NULL 

sv. recv_f inflag 

-  NULL 

sv.send  i sn 

»  NULL 

sv. send_next 

*=  NULL; 

sv.send_una 

-  NULL; 

sv. send_wndw 

=  NULL; 

sv.send_push 

-  NULL; 

sv.send_urg 

*=  NULL; 

sv. send_f inflag 

=  NULL; 

sv.send_f ree 

-  NULL; 

sv.send_lastupl 

«  NULL; 

sv. send_l astup2 

=  NULL; 

sv . send_max_seg 

-  NULL; 

end; 


6.3.6.3*25  raise  prec  The  raise  precedence  action  procedure  raises  the  pre¬ 
cedence  level  recorded  in  the  state  vector  to  the  level  provided  by  the  remote 
TCP.  Section  6.1. 9  of  the  entity  overview  discusses  precedence  negotiation 
during  connection  establishment. 

The  data  effects  of  this  procedure  are: 

-  Data  examined:  from_NET. type_of_serv i ce . precedence 

-  Data  modified:  sv.actua!_prec 

--A  SYN  from  the  remote  TCP  carries  a  precedence  level 
— greater  than  that  indicated  by  the  local  ULP. 

— Precedence  is  carried  as  a  type  of  service  parameter. 
sv.actual_prec  :*  from_NET. type_of_serv i ce . precedence; 
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6.3.6.3-26  record  syn  The  record_syn  action  procedure  records  the 
information  from  the  incoming  segment  containing  a  SYN  flag. 

The  data  effects  of  this  procedure  are: 

-  Data  examined:  all  fields  of  from_NET 

-  Data  modified: 

sv.recv_next 
sv . recv_urg 
sv . recv_i sn 
sv . send_max_seg 
sv . recv_push 

-  Local  variables:  start_seq  amount  offset 


sv . send_wndw 
sv. send_una 
sv.dest i nat ion_por t 
sv.destinati on_addr 


beg  i  n 

—  If  this  half  of  the  connection  was  opened  passively,  the 
— remote  information  should  be  added  to  the  state  vector. 

if  (sv.open_mode  =  PASSIVE) 
then 

sv.destination_port  :=  f rom_NET . seg . source_por t ; 
sv.dest i nat ion_addr  :=*  from_N£T.source_addr ; 

— Record  recv_data. 

sv.recv_isn  :*  f rom_NET.seg.seq_num; 
sv.recv_next  :*  sv.recv_isn; 

— Record  send  data. 

if  (from_NET.seg.ack_f lag  *  TRUE) 

then  sv.send_una  :=  f rom_NET. seg . ack_num; 

--Record  maximum  segment  size  if  present  in  option  field. 

if  ( (f rom_NET . seg .datc_of fset  >  5)  --optionless  header  size 
and  (from_NET.seg.options[0]  =  2))  --Max  Seg  Option  Kind 

then 

sv.send_max_seg  :*  f  rom_NET.  seg  .opt  i on[3.  .**]  ; 

—  If  data  accompanied  the  SYN,  apply  the  implementation 
— dependent  data  acceptance  policy  to  determine  how  much 
— data  should  be  saved,  its  position  in  the  recv_c|ueue, 

--and  its  position  in  the  incoming  segment. 

accept_pol i cy  (  start_seq,  amount,  offset  ); 

if  (amount  >  0) 
then 

add_to_recv(  start_seq,  amount,  offset  ); 

--Update  the  recv_next  sequence  number  if  necessary, 
if  (sv.recv_next  *  start_seq) 
then  sv.recv_next  :»  start_seq  +  amount; 
else  --record  data  position  in  receive  storage  area 


control 


1 


I 


6  July  1982 


System  Development  Corporation 
-I66-  TM-7 172/482/00 


—  implementation  dependent  action 

--Record  PUSH  and  URGENT  information, 
if  ( (f rom_NET.seg.push_f 1 ag  =  TRUE)  and 
(sv.recv_push  <  start_seq  +  amount)) 
then  sv.recv_push  :=  start_seq  +  amount; 

if  ( (f rom_NET. seg .urg_f 1 ag  *  TRUE)  and 

(sv.recv_urg  <  f rom_NET . seg . seq_num  +  f rom_NET . seg . urgptr) ) 
then  --record  the  new  urgent  data  position 

sv.recv_urg  :=  f rom_NET . seg . seq_num  +  from_NET. seg . urgptr ; 
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6.3-6.3-27  reset  The  reset  action  procedure  formats  and  send  a  segment  with 
a  reset  flag  to  the  remote  TCP  to  terminate  the  connection.  RESET  segments 
must  be  formatted  so  that  the  remote  TCP  finds  the  segments  acceptable.  The 
procedure  accepts  one  parameter  indicating  the  format  of  the  RESET  segment  to 
be  sent. 

The  parameter  value  "SEG"  indicates  that  the  incoming  segment  determines  the 
format.  If  the  segment  contains  an  ACK,  this  forms  the  basis  of  the  sequence 
number  in  the  RESET  segment.  If  the  segment  does  not  contain  an  ACK,  the 
RESET  segment  is  made  acceptable  by  carrying  an  ACK  the  incoming  segment's 
text . 

The  parameter  value  CURRENT  indicates  that  the  RESET  is  not  the  result  of  an 
incoming  segment,  but  because  of  a  ULP  abort  request  or  the  ULP  timeout.  In 
such  situations,  the  RESET  segment  is  formed  with  a  sequence  number  based  on 
current  state  vector  values. 

The  data  effects  of  this  procedure  are: 

-  Data  examined: 

sv . source_port 
sv.source_addr 
sv.des t i nat i on_port 
sv.dest i nat ion_addr 

-  Data  modified:  -none- 


sv.sec 

sv.actual_prec 
sv.send_next 
sv.recv  next 


begin 

— Based  on  the  parameter,  set  the  sequence  and  ack  numbers, 
if  (parameter  *  SEG) 

then  — Check  the  incoming  segment  for  ACK  presence, 
if  (from_NET.seg.ack_f lag  =  TRUE) 
then 

to_NET.seg.seq_num  :*»  f rom_NET.seg.ack_num; 

to_NET.seq.ack_f lag  :■  FALSE; 

else 

to_NET.seg.seq_num  :=  0; 

to_NET.seg.ack_f lag  :=  TRUE; 

to_NET.seg .ack_num  :*  f rom_NET.seg .seq_num  + 

(from_NET. length  -  f rom_NET.seg.data_of f set*4)  ; 

else  --parameter  -  CURRENT,  so  use  current  state  vector  values. 
to_NET. seg. seq_num  :*  sv.send_next; 

to_NET.seq.ack_f 1 ag  :«  FALSE; 


--Form  a  segment  using  current  state  vector  data,  set  the 
— reset  flag,  and  transmit  to  the  remote  TCP. 


to_NET.seg.rst_f lag  :■  TRUE; 
to_NET.seg.syn_f lag  :■  FALSE 
to_NET.seg.urg_f lag  :■  FALSE 
to_NET.seg.push_f lag  :■  FALSE 
to_NET. seg. f i n_f 1 ag  :-  FALSE 
to_NET . seg .wi ndow  :■  0; 
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to_NET.seg.data_of f set  :*  OPTI ONLESS_HEADER; 

format_net_params (  0  ); 
compute_checksum; 

TRANSFER  to_NET  to  the  network  protocol  entity; 

end; 
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6.3.6.3.28  reset  self  The  reset_se)f  action  procedure  informs  the  LILP  that 
the  connection  is  terminating,  and  then  sets  the  state  vector  elements  to 
their  initial  values. 

The  reset_se!f  procedure  has  one  parameter  indicating  the  reason  for  connec¬ 
tion  termination.  If  the  parameter  equals  N0_REPQRT,  no  service  response  is 
prepared  for  the  ULP.  All  other  values  produce  service  responses  including  RR 
for  remote  reset,  NF  for  network  failure,  UT  for  ULP  timeout,  SP  for  security 
or  precedence  mismatch,  UC  for  user  close,  and  UA  for  user  abort. 

The  data  effects  of  this  procedure  are: 

-  Data  examined:  sv.lcn 

-  Data  modified:  all  state  vector  elements 


begin 

if  parameter  1!*  N0_REP0RT 
then  beg i n 

case  parameter  of 

when  RA  *■> 

to_ULP .error_desc  :*  "Remote  abort." 
when  NF  ■> 

to_ULP.error__desc  :**  "Network  failure." 
when  SP  «> 

to_ULP.error_desc  :■  "Security/precedence  mismatch." 
when  UT  *■> 

to_ULP .error_desc  :«  "ULP  timeout." 
when  UA  ■> 

to_ULP .error_desc  :■  "ULP  abort." 
when  UC  ■> 

to_ULP .error_desc  :>*  "ULP  close." 
when  SF  ■> 

to_ULP .error_desc  :■  "Service  failure." 
end  case; 


to^ULP.Icn  :«  sv.lcn; 
to__ULP.service_response  :■  TERMINATE; 

TRANSFER  to_ULP  to  the  ULP  identified  by  sv.source_port; 
end; 


— Regardless  of  the  cause,  clear  all 
part_reset; 

sv.source_port  :■  NULL; 
sv.source_addr  :■  NULL; 
sv.destination_port  :-  NULL; 
sv.destination_addr  :-  NULL; 
end; 


queues  and  initialize  state  vector. 

sv.lcn  :»  NULL; 
sv.sec  :■  NULL; 
sv .or i g i na1_prec  :*  NULL; 
sv.actual_prec  :■  NULL; 

sv.ulp_timeout  :*  NULL; 
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6.3.6.3.29  restart  time  wait  The  res  tar t_t i me_wa i t  action  procedure  restarts 
the  currently  running  "time  wait"  timer.  This  procedure  is  called  after  a 
retransmitted  FIN  is  seen  from  the  remote  TCP. 

The  data  effects  of  this  procedure  are: 

-  Oata  examined:  -  none  - 

-  Data  modified:  -  none  - 

— Cancel  the  existing  timer  and  start  it  up  from  scratch. 
cancel_t imer  (  TIME_WAIT,  sv.lcn  ); 

start  timer  (  T I ME_WA I T,  sv.  lcn,  T I ME_WAIT_ INTERVAL  ); 
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6.3.6.3-30  retransm i t  The  retransmit  actions  procedure  resends  data  that  has 
not  been  acknowledged  within  the  retransmission  timeout  interval.  Because  the 
amount  of  data  resent  is  implementation  dependent,  this  decision  is  encapsu¬ 
lated  in  the  retransmi t_pol icy  procedure. 

The  data  effects  of  this  procedure  are: 

Data  examined: 

sv.send_una  sv.send_wndw 

sv.send_next  sv . send_max_seg 

sv.send_push  sv.send_urg 

sv .send_f i nf 1 ag  sv.send_free 

sv.recv_next  sv.recv_wndw 

Data  modi f i ed: 

all  fields  of  to_NET 
retransmission  timer 

-  Local  variables:  retrans_amount  start_pt  pushed_amount 

begin 

--Determine  how  much  data  should  be  retransmitted  to  the 
— remote  TCP. 

retrans_amount  : *  retransmi t_pol icy  () ; 

if  (retrans_amount  >  0) 
then 
begi  n 

--Starting  from  the  front  of  the  retransmission  queue, 

--segment  and  retransmit  data  indicated  by  amount. 

start_pt  :*=  sv.send_una; 
to_NET.seg.seq_num  :■=  start_pt; 
to_NET.seg.rst_f lag  FALSE; 

if  (start_pt  *  sv.send_isn) 
then  --The  SYN  is  being  retransmitted. 
to_NET.seg.syn_f lag  TRUE; 

if  (sv.recv_isn  *  NULL)  — Has  the  remote  TCP  been  heard  from? 
then  to_NET. seg . ack_f I ag  :«  FALSE; 

to_NET.seg.wndw  :■  0; 

else  to_NET.seg.ack_num  :■  sv . recv_next; 

to_NET.seg.ack_f lag  :*  TRUE; 

to_NET. seg.wndw  :■  sv.recv_wndw; 

if  (ttAX_SEGMENT_S I ZE  option  used  in  this  implementation) 
then 

to_NET.seg.options[1]  2;  — See  section  6.2.11 

to_NET.seg.options[2]  :*  A;  — for  option  format. 
to~NET.seg.options[3. .4]  :«  MAX_SEGMENT_S I ZE ; 
to_NET.seg.data_of f set  :*  6; 

else  to_NET.seg.data_off set  :■  OPT  I ONLESS_HEADER; 

else  --Normal  data  retransmission. 

to_NET.seg.ack_num  :■  sv.recv_next; 
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to_NET. seg . ack_f 1 ag  :=  TRUE; 

to_NET. seg . syn_f 1 ag  :=  FALSE; 

to_NET . seg .da ta_of f set  :=  OPT  I QNLESS_HEADER; 

to_NET . seg .wndw  :=  sv . r ecv_wndw; 

— Note  that  this  section  assumes  that  this  segment's  s i ze 
--is  less  than  sv.send_max_seg. 

--The  end  of  pushed  data  cannot  be  packaged  with 
--subsequent  non-pushed  data. 


--Prepare  and  transmit  data. 

dm_copy_f rom_send (  sv.send^una,  retrans_amount  ); 

--If  pushed  data  within  or  following  data  in  this  segment, 
--set  the  PUSH  flag  to  inform  remote  TCP. 
if  (sv.send_una  **<  sv . send_push) 
then  to_NET.seg.push_f lag  :=  TRUE 
else  to_NET.seg.push_f lag  :=  FALSE; 

--If  urgent  data  lies  within  or  follows  data  in  this  segment, 
--record  urgent  data  position  in  header, 
if  (sv.send_urg  >  start_pt) 
then  to_NET.seg.urg_f lag  :=  TRUE; 

to_NET. seg .urgptr  :=  sv.send_urg  -  start_pt; 
else  to_NET. seg .urg_f 1 ag  :=  FALSE; 

--If  this  segment  contains  that  last  octet  of  data  from 
--the  ULP,  set  the  FIN  to  inform  the  remote  TCP. 
if  ( (sv. send_f i nf 1 ag  ■  TRUE)  and 

(sv.send_f ree  *  start_pt  +  retrans_amount) ) 
then  to_NET. seg . f i n_f 1 ag  :*  TRUE 
else  to_NET. seg . f i n_f I ag  :=  FALSE; 

format_net_params (  retrans_amount  ); 
compute_c heck sum; 

TRANSFER  to_NET  to  the  network  protocol  entity; 

end;  — of  preparation  and  retransmission  of  unpushed  data. 


end; 
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6. 3-6. 3. 31  retransm it  policy  As 
retransmi t_po 1 i cy  discusses  the 
It  returns  to  the  calling  action 
retransmi tted . 


one  of 
a  I ternat i ve 
procedure 


the  policy  procedures, 
strategies  for  retransmissions, 
the  number  of  octets  to  be 


A  TCP  implementation  may  employ  one  of  several  retransmission  strategies. 


-  First  only  retransmi ss i on  -  Maintain  one  retransmission  timer  for  the 
entire  queue.  When  the  retransmission  timer  expires,  send  the  segment  at 
the  front  of  the  retransmission  queue.  Initialize  the  timer. 


-  Batch  retransmission  -  Maintain  one  retransmission  timer  for  the  entire 
queue.  When  the  retransmission  timer  expires,  send  all  the  segments  on 
the  retransmission  queue.  Initialize  the  timer. 


Individual  retransmission  -  Maintain  one  timer  for  each  segment  on  the 
retransmi ss i on  queue.  As  the  timers  expire,  the  retransmit  the  segments 
individually  and  reset  their  timers. 


The  first  only  retransm i ss i on  strategy  is  efficient  in  terms  traffic  generated 
because  only  lost  segments  are  retransmitted;  but  the  strategy  can  cause  long 
delays.  The  batch  retransmi ss i on  creates  more  traffic  but  decreasing  the 
likelihood  of  long  delays.  However,  the  actual  effectiveness  of  either  scheme 
depends  in  part  on  the  acceptance  policy  of  the  receiving  TCP. 

For  example,  suppose  a  sending  TCP  sends  three  segments,  all  within  the  send 
window,  to  a  receiving  TCP.  The  first  segment  is  lost  by  the  network.  A 
receiving  TCP  using  the  "in-order"  acceptance  strategy  discards  the  second  and 
third  segments.  A  receiving  TCP  using  the  "in-window"  strategy  accepts  the 
second  and  third  segments,  but  does  not  acknowledge  or  deliver  any  data  until 
the  lost  segment  arrives. 

Batch  retransmission  fits  better  with  the  in-order  acceptance  strategy  because 
the  receiving  TCP  has  discarded  all  segments.  All  three  segments  must  be 
retransmi tted--the  sooner  the  better.  First-only  retransmi ss ion  fits  better 
with  the  in-window  acceptance  policy  because  only  the  needed  retransmission 
occurs  because  the  receiving  TCP  has  kept  the  segments  within  its  receive  win¬ 
dow  and  awaits  only  the  lost  segment.  The  sending  TCP  may  also  choose  to 
repackage  segments  for  retransmission. 
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6 - 3 • 6 . 3 • 32  save  fin  The  save_f i n  action  procedure  records  the  presence  of  a 
FIN  flag  in  an  incoming  segment  received  before  a  connection  is  ESTABLISHED. 
The  FIN  is  processed  only  in  the  ESTABLISHED  state. 

The  data  effects  of  the  procedure  are: 

-  Data  examined:  sv.recv_next 

-  Data  modified:  sv.recv_fin  sv.recv_push 

--Record  FIN  is  recv_var i ab 1 e . 
sv. recv_f i nf 1 ag  :=  TRUE; 

sv.recv_push  :*  sv . recv_next ;  --The  PUSH  function  is  assumed. 

6.3.6.3.33  save  send  data  The  save_send_data  action  procedure  saves  the  data 
provided  by  the  local  ULP  in  a  "Send"  or  an  "Active  Open  with  Data"  service 
request  issued  before  the  connection  is  ESTABLISHED. 

The  data  effects  of  the  procedure  are: 

-  Data  examined  only: 

f rom_ULP .data  f rom_ULP . 1 ength 

f rom_ULP . push_f 1 ag  f rom_ULP .urgent_f 1 ag 

-  Data  mod i f i ed : 

sv.send_free  sv.send_urg 

sv. send_push 

beg  i  n 

--Take  the  data  and  add  it  to  the  send  queue. 

dm_add_to_send  (  sv.send_f ree,  from_ULP . 1 ength  ); 
sv.send_free  :=  sv.send_free  +  from_ULP . 1 ength ; 

--Set  the  urgent  and  push  information  as  needed, 
if  (f rom_ULP . push_f 1 ag  *  TRUE) 
then  sv.send_push  :=  sv.send_f ree; 

if  (f rom_ULP.urg_f 1 ag  =  TRUE) 
then  sv.send_urg  :=  sv. send_f ree; 


end; 
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6 . 3 . 6 . 3 . 34  send  ack  The  send_ack  procedure  formats  and  sends  an  empty 
ment  with  the  ACK  value  indicated  by  parameter. 

The  data  effects  of  this  procedure  are: 

-  Data  examined: 

sv.send_next  sv. source_port 

sv.recv_next  sv . des t i nat i on_por t 

sv.actual_prec  sv.sec 

-  Data  modified:  all  to_NET.seg  fields 


beg  i  n 

— The  ACK  field  of  the  segment  is  set  to  the  parameter  value. 
to_NET . seg . ack_f 1 ag  :«  TRUE; 
to_NET.seg.ack_num  :=  parameter; 


-Fill  in  the  rest  of  the  segment  and  network  parameters. 


to_NET . seg . seq_num 
to_NET.seg.rst_f lag 
to_NET . seg . syn_f  1  ag 
to_NET . seg . push_f I ag 
to_NET  .seg.fi  n_f  1  ag 
to_NET. seg .data_of f set 
to_NET . seg .w i ndow 


=  sv.send_next; 

=  FALSE; 

*  FALSE; 

=  FALSE; 

-  FALSE; 

=  OPT  I ONL£SS_HEADER; 

*  sv . recv_wndw; 


--Add 

--Add 


security  and  precedence  information  to  header, 
in  urgent  information  if  needed, 
if  (sv.send_urg  >  to_NET. seg . seq_num) 


then 

— record  urgent  data 

pos i t i on  in  header 

to_NET . seg . urg_f 1 ag 

=  TRUE; 

to_NET. seg .urgptr 

=  sv.send  urg  -  to 

el  se 

to_NET . seg . urg_f 1 ag 

=  FALSE; 

f ormat_net_params (  0  )  ; 
compute_c heck sum; 

TRANSFER  to_NET  to  the  network  protocol  entity; 

--Adjust  implementation  dependent  ACK  parameters  such  as 
— ACK  timer,  or  state_vector  element  for  the  last  ACK'd  octet, 
end; 


seg- 
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6.3.6.3.35  send  f i n  The  send_fin  action  procedure  records  a  close  reouest 
and,  if  no  data  is  waiting  to  be  transmitted,  formats  and  sends  an  empty  seg¬ 
ment  with  the  FIN  flag  set.  If  data  is  waiting  and  the  window  permits,  the 
FIN  is  sent  along  with  the  data. 

The  data  effects  of  this  procedure  are: 


Data  examined:  sv.send  next 


-  Data  modified:  sv . send_f i nf I ag  sv.send_push 


■-Record  the  CLOSE  service  request.  The  CLOSE  implies  a  PUSH, 
sv. send_f i nf 1 ag  :=  TRUE;  . 
sv.send_push  :=  sv . send_next ; 


--The  FIN  is  sent  along  with  any  waiting  data, 
send  new  data; 
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6.3-6.3.36  send  new  data  The  send_new_data  action  procedure  examines  the 
send  window,  the  amount  of  pushed  data,  and  segment  size  restrictions  to 
determine  if  any  waiting  data  can  be  sent  to  the  remote  TCP.  The  data  effects 
of  this  procedure  are: 


-  Date  examined: 

sv. send_max_seg 
sv.source_port 
sv.des  t i nat i on_por  t 


sv . recv_next 
sv . recv_wndw 
sv . send_f inflag 


Data  mod i f i ed : 

sv.send_next 
sv.send_f ree 
sv.send  wndw 


sv.send_push 

sv . send_urg 

all  fields  of  to  NET 


-  Local  variables:  send  amount 


beg  i  n 

— The  amount  of  data  to  be  sent  is  determined  by  the 
--send  window,  the  amount  of  data  waiting,  the  amount  of 
— pushed  data,  and  segment  size  restrictions. 

if  ( (sv.send_wndw  !!=  0)  and  (sv.  send_next  !  !  ■  sv.send_f ree) ) 
then  begin 

— Data  can  be  sent,  but  how  much? 

— Check  for  pushed  data,  which  must  be  sent  as  soon 
--as  the  window  allows, 
beg  i  n 

if  (sv.send_push  >  sv . send_next) 
then  --Pushed  data  awaits  transmission 


if  (sv . send_push  <  sv.send_una  +  sv . send_wndw) 
then  — all  pushed  data  can  be  sent 

send_amount  :a  sv.send_push  -  sv.send_next; 
to_ULP.seg.push_f lag  :*=  TRUE; 
else  --send  all  pushed  data  allowed  by  send  window 

send_amount  :»  sv.send_una  +  sv.send_wndw  -  sv.send_next; 
to_NET.seg.push_f lag  :=  FALSE; 
else  --No  pushed  data  waiting.  Refer  to  send  policy 
--to  determine  amount  (if  any)  to  be  sent. 
send_amount  :*  send_pol i cy  0  ; 
to_NET. seg .push_f 1 ag  :=  FALSE; 


— How  much  data  to  send  has  been  determined.  Now 
— format  and  transmit  the  segment, 
if  (send  amount  >  0) 


then  begin 

to_NET . seg . seq_num 
to_NET . seg . ack_num 
to_NET . seg . ack_f 1 ag 
to_NET . seg . syn_f I ag 
to_NET.seg.rst_f lag 


■  sv . send_next ; 

■  sv.recv  next; 

-  TRUE; 

-  FALSE; 

-  FALSE; 
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to_NET . seg .data_of f set  :=  OPT  I 0NLESS_HEADER; 
to_NET . seg .wi ndow  :=  sv . recv_wndw; 

--Add  security  and  precedence  to  header. 

— The  ULP  may  have  already  CLOSE-d.  If  so,  and  this 
— data  includes  the  last  octet,  set  the  FIN. 
if  ( (sv . send_f i nf 1 ag  *  TRUE)  and 

(sv.send_f ree  =  to_N£T . seg . seq_num  +  send_amount) ) 
then  to_NET . seg . f i n_f 1 ag  :=  TRUE 
else  to_NET . seg . f i n_f I ag  :=  FALSE; 

if  (sv.send_urg  >  to_NET . seg . seq_num) 
then  --record  urgent  data  position  in  header 
to_NET. seg .urg_f 1 ag  :=  TRUE; 

to_NET.seg.urgptr  :=  sv.send_urg  -  to_NET . seg . seq_num; 
else  to_NET . seg .urg_f 1 ag  :=  FALSE; 

dm_copy_f rom_send (  sv.send_next,  send_amount  ); 
sv.send_next  :=  sv.send_next  +  send_amount; 

format_net_params (  send_amount  ) ; 
compute_checksum; 

TRANSFER  to_NET  to  the  network  protocol  entity; 

— Depending  on  the  retransmission  policy  chosen  for 
--an  impfementation,  a  retransmission  timer 
— may  now  need  to  be  set  for  the  newly  sent  data. 

—  implementation  dependent  action 

end;  — of  preparation  and  transmission  of  data. 

end; 

end; 


6.3.6.3-37  send  pol icy  Barring  pushed  data  and  zero  receive  windows,  the  TCP 
entity  is  left  to  segment  and  transfer  data  at  its  convenience.  The  number  of 
octets  that  should  be  sent  beginning  at  sv.send_next  is  returned  to  the  cal- 
1 i ng  procedure. 

The  definition  of  "convenience"  should  be  influenced  by  design  goals.  If  the 
primary  goal  is  low  overhead  in  terms  of  segment  generation,  then  data  should 
be  accumulated  until  a  maximum  segment's  worth  (defined  by  the  remote  TCP)  is 
ready.  However,  if  quick  response  is  the  main  goal,  the  TCP  entity  should 
segment  and  transmit  data  at  regular  intervals  to  minimize  delay. 

Another  aspect  of  the  send  policy  is  related  to  window  management.  Discussed 
in  the  Section  6.1.2,  the  handling  of  small  send  windows  may  alter  sending 
behavior.  The  TCP  entity  may  choose  to  avoid  sending  into  small  windows 
(where  small  is  defined  as  a  percentage  of  segment  size  or  storage  capaci  ty) 
to  achieve  better  throughput. 
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6.3.6.3.38  set  f i n  The  set_fin  action  procedure  records  the  presence  of  a 
FIN  in  an  incoming  segment.  The  ULP  is  informed  of  the  remote  ULP’s  CLOSE 
after  all  data  from  the  remote  ULP  is  delivered. 

The  data  effects  of  this  procedure  are: 

-  Data  examined:  sv.recv_save  sv.recv_next 

-  Data  modified:  sv . recv_f i nf lag 


begi  n 

— Record  the  FIN's  presence  for  use  in  the  ESTABLISHED  state, 
sv . recv_f i nf I ag  :  =  TRUE; 
sv.recv_push  :*  sv.recv_next; 

--If  no  data  is  waiting  to  be  delivered,  a  CLOSING 
— service  response  is  issued  to  inform  the  local  ULP  of  the 
— remote  ULP's  CLOSE  request. 

if  (sv . recv_save  =  sv.recv_next) 

and  (no  data  is  awaiting  re-ordering) 

then 

to_ULP.servi ce_response  :=  CLOSING; 
to_ULP.Icn  :*  sv.lcn; 

TRANSFER  to_ULP  to  the  ULP  named  by  sv . source_por t . 

end; 

6.3.6.3.39  start  time  wai t  The  star t_t i me_wa i t  action  procedure  cancels  all 
other  timers  and  sets  the  final  "TIME_WAIT"  timer  which  allows  time  for  the 
final  FIN  acknowledgement  to  reach  the  remote  TCP  before  clearing  the  state 
vector  of  this  connection. 

The  data  effects  of  this  procedure  are: 

-  Data  examined:  -  none  - 

-  Data  modified:  -  none  - 
begin 

--Issue  timer  cancellation  requests  to  the  execution  environment 
--corresponding  to  all  current  timers. 
cancel_timer  (  ULP_TIMEOUT  ); 
cancel_timer  (  RETRANSMIT  ); 

— Depending  on  implementation  strategies,  ACK  timers  and 
--zero  window  timers  may  also  exist. 

— Start  up  the  time_wait  timer  for  the  appropriate  duration — currently 
— suggested  to  be  2  minutes. 

start_timer  (  TIME_WAIT,  TIME_WAIT  INTERVAL  ); 


end; 
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6.3-6.3.40  update  The  update  routine  takes  a  new  ACK  from  the  incoming  seg¬ 
ment  to  update  the  send  and  receive  variables.  The  data  effects  of  this  pro¬ 
cedure  are: 

-  Data  examined: 

f  rom_N£T . seg . ack_num  f  rom_NET . seg .wi ndow 

f rom_NET . seg . seq_num 

-  Data  mod i f i ed: 

sv.send_una  sv.send_wndw 

sv. send_l astupl  sv . send_l astup2 


beg  i  n 

--Take  only  new  ACKs,  i .e.  those  greater  than  sv.send_una. 

if  f rom_NET. seg . ack_num  >  sv.send_una 

then  begin  --update  the  retransmission  queue 

dm_remove_f rom_send (sv . send_una ,  (f rom_NET. seg . ack_num  -  sv . send_una) ) ; 
sv.send_una  :«  f rom_NET.seg.ack_num; 

— Depending  on  retransmission  strategy,  the  retransmission 
--timer  may  need  resetting  because  of  the  new  ACK. 

—  implementation  dependent  action 

--The  retransmission  timeout  interval  may  need  adjustment 
--to  adapt  to  the  round-trip  time  of  the  data  just  ACK-ed. 
--implementation  dependent  action 

— The  l)LP  timeout  timer  may  need  resetting  due  to  the 
--the  successful  delivery  of  the  newly  ACK-ed  data. 

--implementation  dependent  action 

end; 

--A  new  window  is  provided  if  either  the  sequence  number  of  this 
--segment  is  newer  than  the  one  last  used  to  update  the  window,  or 
--(for  1-way  data  transfer)  the  sequence  number  is  the  same  but 
--the  ACK  is  greater. 

if  ((sv.send_lastupl  <  f rom_NET. seg . seq_num)  or 

(sv . send_l astup2  <  f rom_NET.seg .ack_num) ) 

then  begin 

sv.send_wndw  :*  (f rom_NET. seg . ack_num  +  from_NET. seg .wi ndow) 

-  sv.send_una; 

sv.send_lastupl  :=  f rom_NET. seg . seq_num; 
sv.send_lastup2  :=  f rom_NET . seg . ack_num; 

--Because  a  new  send  window  has  arrived,  try  to  send  data, 
send  new  data; 


end; 


end ; 
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7.  EXECUTION  ENVIRONMENT  REQUIREMENTS 

Throughout  this  document,  the  environmental  model  portrays  each  protocol 
entity  acting  as  an  independent  process.  Within  this  model,  the  execution 
environment  must  provide  two  facilities:  inter-process  communication  and  tim- 
i  ng . 

7.1  INTER-PROCESS  COMMUNICATION 

The  execution  environment  must  provide  an  inter-process  communication  facility 
to  enable  independent  processes  to  pass  units  of  information,  called  messages. 
For  TCP's  purposes,  the  I  PC  facility  is  required  to  preserve  the  order  of  mes¬ 
sages  . 

TCP  uses  the  I  PC  facility  to  exchange  interface  parameters  and  data  with  upper 
layer  protocols  across  its  upper  interface  and  the  network  protocol  across  the 
lower  interface.  Sections  3  and  5  specify  these  interfaces. 

In  the  service  and  entity  specifications,  this  service  is  accessed  through  a 
the  following  primitive: 

1.  TRANSFER  -  passes  a  message  to  a  named  target  process. 

7.2  TIMING 


The  execution  environment  must  provide  a  timing  facility  that  maintains  32-bit 
clock  (possibly  fictitious)  with  units  no  coarser  than  1  second.  A  process 
must  be  able  to  set  a  ti..ier  for  a  specific  time  period  and  be  informed  by  the 
execution  environment  when  the  time  period  has  elapsed.  A  process  must  also 
be  able  to  cancel  a  previously  set  timer. 

Several  TCP  mechanisms  use  the  timing  facility.  The  positive  acknowledgement 
with  retransmission  mechanism  uses  timers  to  ensure  that  if  data  or  ack¬ 
nowledgements  are  lost,  they  are  re-sent.  The  ULP  timeout  mechanism  uses  the 
timing  facility  to  clock  the  delay  between  data  transmission  and  acknowledge¬ 
ment.  The  time-wait  mechanism  uses  a  timer  to  allow  enough  time  for  a  final 
FIN  acknowledgement  to  arrive  at  the  remote  TCP  entity  before  connection  ter¬ 
mination.  Other  uses  for  a  timing  facility  are  implementation  dependent. 

In  the  upper  service  and  entity  specification,  the  timing  services  are 
accessed  with  the  following  primitives: 

1.  SET_T1MER (timer_name,  time_interval)  -  allows  a  given  interval  of  time 
and  an  identifier  to  be  specified.  After  the  specified  interval  elapse, 
and  timeout  indication  and  the  identifier  is  returned  to  the  issuing  pro¬ 
cess  . 

2.  CANCEL_TIMER  (timer_name)  -  allows  the  timeout  associated  with  the  iden¬ 
tifier  to  be  terminated. 

3.  CURRENT_TIME  -  returns  the  current  time. 
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8.  GLOSSARY 


Acknow I edqement  Number 

A  32-bit  field  of  the  TCP  header  containing  the  next  sequence  number  expected 
by  the  sender  of  the  segment. 

ACK 

Acknowledgement  flag:  a  control  bit  in  the  TCP  header  indicating  that  the  ack¬ 
nowledgement  number  field  is  significant  for  this  segment. 

Checksum 

A  16-bit  field  of  the  TCP  header  carrying  the  one's  complement  based  checksum 
of  both  the  header  and  data  in  the  segment. 

connect i on 

A  logical  communication  path  identified  by  a  pair  of  sockets. 
datagram 

A  self-contained  package  of  data  carrying  enough  information  to  be  routed  from 
source  to  destination  without  reliance  on  earlier  exchanges  between  source  or 
destination  and  the  transporting  network. 

datagram  serv i ce 

A  datagram,  defined  above,  delivered  in  such  a  way  that  the  receiver  can 
determine  the  boundaries  of  the  datagram  as  it  was  entered  by  the  source.  A 
datagram  is  delivered  with  high  probability  to  the  desired  destination,  but  it 
may  possibly  be  lost.  The  sequence  in  which  datagrams  are  entered  into  the 
network  by  a  source  is  not  necessarily  preserved  upon  delivery  at  the  destina¬ 
tion. 

Data  Offset 

A  TCP  header  field  containing  the  number  of  32-bit  words  in  the  TCP  header. 
Pest i nat i on  Address 

The  destination  address,  usually  the  network  and  host  identifiers.  Although 
not  carried  in  the  TCP  header,  this  value  is  passed  to  and  received  from  the 
network  protocol  entity  with  each  segment. 

Pest i nation  Port 

The  TCP  header  field  containing  a  2-octet  value  identifying  the  destination 
upper  level  protocol  of  a  segment's  data. 

FIN 

A  control  bit  of  the  TCP  header  indicating  that  no  more  data  will  be  sent  by 
the  sender. 

header 

The  collection  of  control  information  transmitted  with  data  between  peer  enti¬ 
ties. 

host 

A  computer,  particularly  a  source  or  destination  of  messages  from  the  point  of 


1 
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view  of  the  communication  network. 

I  dent i f i cat i on 

A  value  passed  with  each  segment  to  the  network  protocol  entity  (Internet  Pro¬ 
tocol).  This  identifying  value  assigned  by  the  sending  TCP  aids  in  assembling 
the  fragments  of  a  datagram. 

internetwork 

A  set  of  interconnected  subnetworks. 
i nternet  address 

A  *four  octet  (32  bit)  source  or  destination  address  composed  of  a  Network 
field  and  a  Local  Address  field. 

i nternet  datagram 

The  package  exchanged  between  a  pair  of  IP  modules.  It  is  made  up  of  an 

internet  header  and  a  data  portion. 

J_P 

Internet  Protocol 
ISN 

Tiie  Initial  Sequence  Number.  The  first  sequence  number  used  for  either  send¬ 
ing  or  receiving  on  a  connection.  It  is  selected  on  a  clock  based  procedure. 

ft 

local  network 

The  network  directly  attached  to  host  or  gateway. 
module 

An  implementation,  usually  in  software,  of  a  protocol  or  other  procedure. 

MSL 

Maximum  Segment  Lifetime,  the  time  a  TCP  segment  can  exist  in  the  internetwork 
system.  Arbitrarily  defined  to  be  2  minutes. 

octet 

An  eight  bi t  byte. 

Options 

The  optional  set  of  fields  at  the  end  of  the  TCP  header  used  in  a  SYN  segment 
to  carry  the  maximum  segment  size  acceptable  to  the  sender. 

packet 

The  unit  of  data  transmitted  by  a  packet-switched  network.  A  packet  usually 
contains  nested  control  information  and  data  from  the  higher  layer  protocols 
using  the  network. 

packet  network 

A  network  based  on  packet-switching  technology.  Messages  are  split  into  small 
units  (packets)  to  be  routed  independently  on  a  store  and  forward  basis.  This 
packetizing  pipelines  packet  transmission  to  effectively  use  circuit 
bandwidth. 


System  Development  Corporation 
6  July  1982  -184-  TM-7172/482/OO 

Padd i nq 

A  header  field  inserted  after  option  fields  to  ensure  that  the  data  portion 
begins  on  a  32-bit  word  boundary.  The  padding  field  value  is  zero. 

port 

The  portion  of  a  socket  that  specifies  the  upper  level  protocol  associated 
wi th  the  data . 

precedence 

A  measure  of  datagram  importance.  It  is  one  of  the  service  quality  parameters 
supported  by  the  Internet  Protocol's  type  of  service  mechanism. 

PUSH 

A  control  bit  of  the  TCP  header  occupying  no  sequence  space,  indicating  that 
this  segment  contains  data  that  must  be  pushed  through  to  the  receiving  ULP. 

push  serv i ce 

A  service  provided  by  TCP  to  the  upper  level  protocols.  A  push  directs  TCP  to 
segment,  send,  and  deliver  data  received  up  to  that  point  as  soon  as  flow  con¬ 
trol  permits. 

receive  next  sequence  number 

The  next  sequence  number  a  TCP  is  expecting  to  receive. 
receive  wi ndow 

This  represents  the  sequence  numbers  a  TCP  is  willing  to  receive.  Thus,  the 
TCP  considers  that  segments  overlapping  the  range  RECV_NEXT  to  RECV_NEXT  + 
RECV_WND  -  1  carry  acceptable  data  or  control.  Segments  containing  sequence 
numbers  entirely  outside  of  this  range  are  considered  duplicates  and  dis¬ 
carded  . 

reliability 

A  quality  of  data  transmission  defined  as  guaranteed,  ordered  delivery. 
Reserved 

A  6-bit  field  of  the  TCP  header  that  is  not  currently  used  but  must  be  zero. 
RST 

A  control  bit  of  the  TCP  header  indicating  that  the  connection  associated  with 
this  segment  is  to  be  terminated. 

segment 

The  unit  of  data  exchanged  by  TCP  modules.  This  term  may  also  be  used  to 
describe  the  unit  of  exchange  between  any  transport  protocol  modules. 

segment  1 ength 

The  amount  of  sequence  number  space  occupied  by  a  segment,  including  any  con¬ 
trols  which  occupy  sequence  space. 

send  sequence 

This  is  the  next  sequence  number  the  TCP  will  use  to  send  data  on  the  connec¬ 
tion.  It  is  initially  selected  from  an  initial  sequence  number  curve  (ISN) 
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and  is  incremented  for  each  octet  of  data  or  sequenced  control  transmitted. 
send  w i ndow 

This  represents  the  sequence  numbers  which  the  remote  TCP  is  willing  to 
receive.  It  is  the  value  of  the  window  field  specified  in  segments  from  the 
remote  (data  receiving)  TCP.  The  range  of  new  sequence  numbers  which  may  be 
emitted  by  a  TCP  lies  between  SEND_NEXT  and  SENDJJNA  +  SEND_WNDW  -  1. 
(Retransmissions  of  sequence  numbers  between  SEND_UNA  and  SND_NEXT  are 
expected,  of  course.) 

Sequence  Number 

A  32-bit  field  of  the  TCP  header  containing  the  sequence  number  of  the  1)  a 
sequenced  control  flag  (if-  present),  or  2)  the  first  byte  of  data  (if 
present),  or,  3)  for  empty  segments,  the  sequence  number  of  the  next  data 
octet  to  be  sent. 

socket 

An  address  which  specifically  includes  a  port  identifier,  that  is,  the  con¬ 
catenation  of  an  Internet  Address  with  a  TCP  port. 

Source  Por  t 

The  TCP  header  field  containing  a  2-octet  value  identifying  the  source  upper 
level  protocol  of  a  segment's  data. 

TCP  segment 

The  package  exchanged  between  TCP  modules  made  up  of  the  TCP  header  and  a  text 
portion  (which  may  be  empty). 

ULP 

Upper  Level  Protocol:  any  protocol  above  TCP  in  the  layered  protocol  hierarchy 
that  uses  TCP.  This  term  includes  presentation  layer  protocols,  session  layer 
protocols,  and  user  applications. 

Urgent  Pointer 

A  TC>  header  field  containing  a  positive  offset  to  the  sequence  number  of  the 
segment  indicating  the  position  of  urgent  data  in  the  connection's  data 
stream.  This  field  is  valid  only  when  the  URG  flag  is  on. 

URG 

A  control  bit  of  the  TCP  header  indicating  that  the  urgent  field  contains  a 
valid  pointer  to  urgent  information  in  the  connection's  data  stream. 

W i ndow 

A  2-octet  field  of  the  TCP  header  indicating  the  number  of  data  octets  (rela¬ 
tive  to  the  acknowledgement  number  in  the  header)  that  the  segment  sender  is 
currently  willing  to  accept. 
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APPEND  I 


A:  Retransmission  Strategy  Effectiveness 


As  noted  in  the  entity  overview,  Section  6.1,  a  TCP  implementation  may  employ 
one  of  several  retransmission  strategies: 


a.  First-only  retransmission  -  A  TCP  maintains  one  retransmission  timer  for 
the  queue,  retransmitting  the  front  segment  (or  segment's  worth  of  data) 
when  the  timer  expires. 


b.  Batch  retransmission  -  A  TCP  maintains  one  retransmission  timer  for  the 
queue,  retransmitting  all  segments  on  the  queue  when  the  timer  expires. 

c.  Individual  retransmission  -  A  TCP  maintains  one  timer  per  segment  on  the 
queue,  retransmitting  each  segment  when  its  individual  timer  expires. 


The  first-only  retransmission  strategy  is  efficient  in  terms  traffic  generated 
because  only  lost  segments  are  retransmitted;  but  the  strategy  can  cause  long 
delays.  The  batch  retransmission  creates  more  traffic  but  decreases  the 
likelihood  of  long  delays.  The  individual  retransmission  strategy  is  a 
compromise  between  delay  and  traffic  but  requires  much  more  processing  time 
from  the  TCP  entity.  However,  the  actual  effectiveness  of  each  scheme  depends 
in  part  on  the  acceptance  policy  (Section  6 . 1 . 3)  of  the  receiving  TCP. 

For  example,  suppose  a  sending  TCP  sends  three  segments,  all  within  the  send 
window,  to  a  receiving  TCP.  The  first  segment  is  lost  by  the  network.  A 
receiving  TCP  using  the  "in-order"  acceptance  strategy  discards  the  second  and 
third  segments.  A  receiving  TCP  using  the  "in-window"  strategy  accepts  the 
second  and  third  segments,  but  does  not  acknowledge  or  deliver  any  data  until 
the  intervening  segment  arrives. 

Batch  retransmission  performs  better  with  the  in-order  acceptance  strategy 
because  the  receiving  TCP  has  discarded  all  segments.  All  three  segments  must 
be  retransmi tted--the  sooner  the  better.  First-only  retransm i ss i on  performs 
better  with  -he  in-window  acceptance  policy  because  only  the  necessary 
retransmissions  occur  since  the  receiving  TCP  has  kept  the  segments  within  its 
receive  window  and  awaits  only  the  lost  segment. 

Unfortunately,  a  sending  TCP  cannot  knc  .  what  acceptance  policy  is  being  used 
by  the  receiving  TCP.  Instead,  the  retransmission  strategy  must  be  chosen 
according  implementation  dependent  and  configuration  dependent  design  goals. 


microcopy  resolution  test  chart 
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APPENDIX  B:  Dynamic  Retransmission  Timer  Computation 

Because  of  the  variability  of  the  networks  that  compose  and  internetwork  sys¬ 
tem  and  the  wide  range  of  uses  of  TCP  connections,  the  retransmission  timeout 
should  be  dynamically  determined.  One  procedure  for  determining  a  retransmis¬ 
sion  time  out  is  give  her  as  an  illustration. 


Measure  the  elapsed  time  between  sending  a  data  octet  with  a  particular 
sequence  number  and  receiving  an  acknowledgement  that  covers  that  sequence 
number.  (Segments  sent  do  not  have  to  match  segments  received.)  This  meas¬ 
ured  elapsed  time  is  the  Round  Trip  Time.  Next,  compute  a  Smoothed  Round  Trip 
Time  (SRTT)  as: 

SRTT  -  (  ALPHA  *  SRTT)  +  ((1 -ALPHA)  *  RTT) 
and  based  on  this,  compute  the  retransmission  timeout  (RTO)  as: 

RTO  *  mi nimum  (UBOUND ,  maximum  (LBOUND,  (BETA*SRTT) )) ) 
where: 

UNBOUND  *  an  upper  bound  on  the  timeout  (e.g.,  1  minute) 

LBOUND  -  a  lower  bound  on  the  timeout  (e.g.,  1  second) 

ALPHA  “  a  smoothing  factor  (e.g.,  .8  to  .9) 

BETA  ■  a  delay  variance  factor  (e.g.,  f.3  to  2.0) 


l 


6  July  1982 


-189- 


System  Development  Corporation 
TM-7 172/482/00 


APPENDIX  C:  Alternatives  in  Service  Interface  Primitives 


The  service  primitives  offered  to  the  upper  level  protocol  are  specified  in 
section  3.1.  The  service  request  primitives  are: 

-  Unspecified  Passive  Open, 

-  Fully  Specified  Passive  Open, 

-  Active  Open 

-  Active  Open  with  Data, 

-  Send, 

-  A 1  locate, 

-  Status, 

-  Close,  and 

-  Abort 

These  primitives  support  the  minimal  services  required  of  a  TCP.  However, 
combinations  or  modifications  may  offer  additional  services  that  are  tailored 
to  the  requirements  of  a  particular  set  of  upper  level  protocols.  Several 
examples  are  provided  below. 

If  the  protocol  supporting  TCP  is  the  Internet  Protocol  and  a  TCP  implementa¬ 
tion  wishes  to  export  IP's  option  services  [3]  (including  source  routing, 
record  routing,  stream  identification  and  timestamps),  an  addtional  "options" 
parameter  would  be  required  in  all  Open  and  Send  service  requests. 

An  upper  level  protocol  may  need  a  reliable  transaction  service.  That  is,  a 
ULP  may  wish  to  open  a  connection,  send  a  single  message,  and  then  close  the 
connection.  To  access  this  service,  the  specified  service  interface  requires 
the  ULP  to  issue  at  least  two  service  primitives,  an  Open  with  Data  and  a 
Close,  to  excercise  this  service.  A  TCP  may  be  designed  with  a  service  primi¬ 
tive  that  combined  the  Open  and  Close  to  form  a  new  primitive,  called  perhaps 
Transaction,  which  would  include  all  the  Open  parameters,  the  data  to  be 
transmitted,  and  the  signal  to  close  the  connection  after  data  delivery. 

The  upper  layer  service  definition  (Section  3-2)  does  not  allow  a  Passive  Open 
request  to  be  followed  by  an  Active  Open  request.  Instead,  the  ULP  must  first 
issue  a  Close  or  Abort  request  to  cancel  the  Passive  Open  request,  then  issue 
an  Active  Open  request.  A  TCP  may  be  designed  to  allow  "conversion"  of  open 
requests  from  passive  to  active.  In  this  case,  a  ULP  could  issue  a  Full  Pas¬ 
sive  Open  request  followed  by  an  Active  Open  or  a  Send  request  to  actively 
initiate  a  connection.  Thus,  the  local  entity  service  diagram  (appearing  in 
Section  3*2)  changes  to  include  a  transition  from  the  PASSIVE  to  the  ACTIVE 
state  as  shown  below: 
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